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(57) Abstract 

A system wherein, generally, geolocation data, 
map database information, and processing techniques 
effect the generation and use of map database infor- 
mation, especially to provide custom travel-related in- 
formation such as dynamic route planning and guid- 
ance. The system typically generates the map data- 
base information from the movement of vehicles by 
passively geolocating and tracking at least one vehicle 
carrying a mobile transmitter. The generated informa- 
tion may be stored in a database of location-sensitive 
data for other purposes. Custom travel-related infor- 
mation is provided to a vehicle by passively geolocat- 
ing the vehicle's mobile transmitter (typically a cel- 
lular phone), selecting relevant travel-related informa- 
tion from a database of location-sensitive data, and 
sending the selected information to the vehicle's mo- 
bile receiver (typically a cellular phone). Using a data- 
base of location-sensitive data that was derived, in part, 
by passively geolocating vehicles' mobile transmitters, 
custom travel-related information is also provided to a 
third party user who is not necessarily in a vehicle. 
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GENERATION AND DELIVERY OF 
TRAVEL-RELATED, LOCATION-SENSITIVE INFORMATION 

BACKGROUND OF THE DISCLOSURE 

1. Field of the Invention 

This invention relates generally to travel systems, and, more particularly, to 
methodologies and concomitant circuitry for automatically generating map database data 
using geolocation information obtained by passively geolocating vehicular traffic, for 
reconciling generated map database data against a pre-existing map database, and for 
deploying a map database to provide travel-related information. 

2. Description of the Background 

Research investigations into technology for locating vehicular traffic have 
culminated in the development and deployment of numerous commercial systems and 
products based on such technology. Aspects of these investigations pertinent to the subject 
matter of the present invention are summarized below from the following points of view: 
(a) map database systems; (b) vehicle location systems; and (c) systems combining map 
database and vehicle location systems to provide travel information. The systems of (a)- 
(c) overlap in many respects, and the primary emphasis of the discussion for each of the 
systems follows from the topical heading of each sub-section; in this manner these 
overlaps will be readily understood and appreciated by those with ordinary skill in the art. 

(a) Map Database Systems 

An example of one type of commercial map database system is an in-vehicle 
navigation system recently introduced by some automobile manufacturers and rental car 
agencies ~ such a system guides the driver of the car equipped with the navigation system 
to a desired destination. The in-vehicle system is generally composed of: (1) a global 
positioning system (GPS) receiver carried by the vehicle; (2) an in-vehicle computer 
system responsive to the GPS receiver, with the computer system being configured with a 
map database covering a pre-determined area (typically the area within a radius of the car 
rental agency, that is, the anticipated area of use by the car rental driver); (3) a device for 
inputting to the computer the desired destination; and (4) a small video monitor mounted 
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on the dashboard to display the computer-selected route to the desired destination on the 
local map. 

While such an in-vehicle system does provide a convenience to a traveler 
unfamiliar with a local area, the system is somewhat expensive because costly equipment 
5 mU st be replicated for each vehicle. Moreover, if a rental car is driven outside the 
anticipated radius covered by the local map, and the map database is not changed to 
reflect the new local area, then the system is virtually useless. Because the system is 
totally self-contained within the vehicle, there is no feasible way to download a map 
database representative of the current travel area. 
10 Most importantly, however, is the obvious fact that guidance systems of this type 

are highly dependent upon updates to the local map database. For instance, if the map 
database itself is not updated regularly and/or an updated map database is not loaded into 
the in-vehicle computer, then, for example, the proposed route may be circuitous if a 
freeway has recently been constructed but it is not included in the map database, or the 
,5 suggested route may inadvertently use a road that is temporarily closed for construction 
because an updated map database has not been loaded into the on-board computer. 

DeLorme, a map maker, has addressed the issue of regularly updating its map 
databases, but in a fundamentally different context. DeLorme provides a commercial map 
database product on CD-ROM, along with trip-planning software, whereby a user of the 
20 CD-ROM product may have a trip automatically determined, prior to a planned trip, by 
the software - the user inputs the starting point and the destination point, and a computer 
accessing the CD-ROM outputs the route in paper format. To update the map database, 
DeLorme provides access to its World Wide Web site for current information such as 
weather forecasts, road construction, and other road information of importance to the 
25 computer-generated route. However, updates are only as current as the latest information 
loaded by the Web site administrator. The updated information may be as old as hours or 
days; it is clear that such information is not being dynamically updated. 

Of course, as alluded to above, even if maps were capable of being updated 
instantaneously, in-vehicle guidance systems still are expensive because each vehicle 
30 carries sophisticated electronic devices. 
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Accordingly, to provide maximal utility to the rental car driver, a meritorious 
advance in the art would provide an up-to-date map with dynamic adjustments for road 
conditions, and even anticipated road conditions ~ such as rush hour traffic. 

(b) Vehicle Location Systems 

Many travel-related systems and techniques depend on the ability to track a 
vehicle's location, as briefly alluded to above, and such tracking can be performed either 
at the vehicle or at a remote site. It is advantageous to track the vehicle, along with other 
vehicles, from at least one remote central site since tracking information provided by the 
plurality of vehicles may be synergistically utilized. 

There are several techniques available for remotely tracking the location of a 
vehicle; conventionally, such techniques are broadly categorized as "active" or "passive" 
geolocation. 

"Active" geolocation techniques require the vehicle to take an active part in 
allowing a central site to determine the location of the vehicle. Active geolocation 
; techniques generally require the vehicle to carry special equipment or initiate a special 
action whose purpose is to allow the vehicle to be geolocated by a central site. 

One technique for active geolocation uses a GPS receiver, which performs 
geolocation using timing signals received from satellites. A GPS receiver, carried in a 
vehicle, can be connected to a transmitter that transmits the vehicle's location to a 
) receiver at a central site. Although the transmission of geolocation data from the vehicle 
to the central site may be accomplished using a transmitter that was not intended 
specifically for geolocation, such as a cellular phone, this GPS technique is still 
considered to be active geolocation because the technique requires the vehicle to carry a 
GPS receiver. 

5 Another technique for active geolocation uses a special-puipose transmitter carried 

with the vehicle, that is intended to allow the vehicle to be geolocated. This is considered 
to be active geolocation because the primary intent of such a special-purpose transmitter is 
to allow the vehicle to be remotely geolocated. 

"Passive" geolocation techniques allow a vehicle's location to be determined by a 
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central site without the vehicle's specific assistance, and typically without the vehicle's 
specific knowledge. Passive techniques do not require the vehicle to carry any special 
equipment whose primary purpose is to allow the vehicle to be geolocated. 

Methods have now been developed to passively geolocate a cellular phone or other 
5 mobile transmitter that was not designed specifically for geolocation purposes. Cellular 
phones have rapidly gained wide popularity, and are commonly used and carried in 
vehicles. This preponderance of vehicles carrying cellular phones and other mobile 
transceivers has led to new capabilities for collecting and delivering travel information. 

Such methods automatically record the location of a mobile cellular telephone 
10 using the standard signals transceived by the mobile cellular phone itself, that is, without 
requiring or relying upon any additional components or signals, because the standard 
mobile cellular phone generates sufficient identifying information in the standard 
transceived signals to record its location. As applied to a vehicular system, this means 
that no additional in-vehicle components are required to locate a cellular mobile telephone 
15 (hence, the vehicle) other than the standard mobile cellular telephone itself. Thus, the 
meritorious advance fostered by these techniques is the ability to locate the cellular 
telephone using an arrangement which is located remotely from the mobile cellular 
telephone » and, therefore, the vehicle carrying the cellular phone. 

L One technique for locating a cellular phone determines the approximate location of 
20 /|[the phone by noting the cell site in which the phone is currently operating. The cellular 
I phone system operates by dividing geographic areas into "cells" which cover a geographic 
| area. The layout of FIG. 1 (from the patent of Stilp, as discussed in more detail below) 
shows several hypothetical cells covering a given geographic area; the different shading of 
the cells represents that each cell employs one of seven distinct frequencies for 
25 transceiving. The cells may be irregularly shaped, but each one represents a particular 
operating area that is typically governed by a single antenna site ("cell site"). As a 
cellular phone travels, it communicates with a cell site that governs the cell in which the 
phone is located a prior art arrangement is shown in FIG. 2 (again from Stilp). To 
allow uninterrupted communications, the cellular phone system monitors the location of 
30 the active cellular phone, and uses a protocol to hand off the call from one cell site to the 
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next as the mobile phone travels out of one cell and into another. Thus, the cellular phone 
system can determine the approximate geographic location of the phone by noting the cell 
site in which the phone is currently operating. This can be accomplished even when the 
cellular phone is in "Standby" mode - it does not require an active call in progress. 

5 Other conventional methods of passive geolocation, which provide a better 

resolution as to the location of the mobile phone, observe a mobile transmitter's radio 
frequency ("RF") transmissions. Various techniques are used, such as measuring the time 
difference of arrival (TDOA) or angle of arrival (AOA) of the phone's RF transmissions 
at a plurality of receivers at known locations. 

io Representative of passive techniques for automatically and remotely locating a 

cellular telephone is the subject matter disclosed by U.S. Patent No. 5,317,323 issued to 
Kennedy et al, U.S. Patent No. 5,327,144 issued to Stilp et al (Stilp), and U.S. Patent 
No. 5,465,289 issued to Kennedy. Considering the system of Stilp as illustrative of 
passive geolocation methods, the cellular telephone location system employs at least three 

15 cell site systems to, in effect, resolve the location of the cellular mobile telephone via 
"triangularization". The cellular telephone system as described by Stilp is repeated in 
FIG. 3, and the details on the description of Stilp are incorporated herein by reference. 
By way of brief overview, the system of Stilp uses three or more cell site systems 12. 
Each cell site includes an antenna as part of system 12. The cell site systems are coupled 

20 to a central site via telecommunications paths 14. The central site 16 is further coupled to 
database 20, which may be remotely located from the central site and made available to 
customers (e.g., elements 22, 24, 10b). Locations of multiple mobile cellular telephones 
are determined by each phone initiating periodic signal transmissions over one of a 
prescribed set of control channels. The central site system processes the signal 

25 transmissions to thereby generate the differences in times of arrival of the signal 

transmissions and, on the basis of the times of arrival, determines the location of the 
cellular telephones originating the cellular telephone signals. 

The pedagogical insight provided by the teachings and suggestions of Stilp with 
respect to the operation of a conventional cellular system, especially as set forth in Stilp 's 

30 background, serve as one point of reference for the departure from the art in accordance 
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with the subject matter of the present invention, 
(c) Travel Information Systems 

Another common need in systems that provide travel-related information is the 
ability to represent road segments and travel time information in a form that is convenient 
5 for algorithmic use, for example, to be able to compute the fastest route from a source to 
a destination. A compilation of road segments and, optionally, travel time information, 
determines a map database for the covered geographical area. A graph representation for 
road segments composing the map database is often convenient for use by algorithms that 
provide traveler information services. Graph theory is a well-developed branch of 
10 computer science and mathematics, and has established many well-known algorithms for 
solving common graph problems. For example, there are several well-known graph 
algorithms for computing the fastest route from a source to a destination. 

In graph theory, a "directed graph" is a set of directed links and a set of nodes. A 
"node" represents an idealized physical position, and would typically have some kind of 

15 map coordinates associated with it. A "link" in a directed graph is a directed connection 
from one node (the "FromNode") to another node (the "ToNode"). A link represents a 
travel path on one or more road segments, leading from the position indicated by the 
FromNode and going to the position indicated by the ToNode. The link may also be 
labeled with additional information, such as the name(s) of the road segment(s) that this 

20 link represents, the travel time required to traverse this link, and the width of the road 

segment(s) that this link represents, as shown in FIG. 4 wherein nodes 107a, 107b, 107c 
and 107d and links 106a, 106b and 106c compose a directed graph. In FIG. 4, link 106b 
connects from its FromNode 107a to its ToNode 107b; link 106c connects from its 
FromNode 107b to its ToNode 107c; and link 106a connects from its FromNode 107b to 

25 its ToNode 107d. Dashed box 105a represents the width of the road segment 
corresponding to link 106a. 

Travel-related systems have been developed that use databases to store location- 
sensitive information such as travel times or traffic conditions for specific areas or road 
segments. Such databases can be characterized as providing either "static" or "dynamic" 
30 information. 
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"Dynamic" location-sensitive information is location-sensitive information that is 
derived from real-time or near-real-time observations of current travel conditions. 
Dynamic information is intended to represent current travel conditions, as opposed to 
average or typical travel conditions. 

"Static" location-sensitive information is location-sensitive information that reflects 
assumed travel conditions and does not make use of current observations or measurements 
of current travel conditions. Static information is usually intended to represent typical 
travel conditions, as opposed to current travel conditions. 

Representative of techniques addressing the tailoring of route information for each 
i individual driver of an automobile traveling within a pre-determined geographical area is 
the subject matter disclosed in U.S. Patent No. 5,523,950 issued to Peterson. As 
disclosed in Peterson, stationary sensors are physically and regularly placed along each 
roadway in a local area over which vehicular traffic will be routed. The sensors measure 
the velocity/speed of each automobile passing each sensor, and this measured speed is, in 
; turn, transmitted to a centralized database. The system of Peterson is more fully 

described with reference to FIG. 5 (FIG. 3 of Peterson). In FIG. 5, which is a stylized 
grid for a region, the interconnecting points for a variety of route segments are 
represented by similar letters A', B', etc. Accordingly, the various route segments may 
be similarly represented as A'-B\ CD', etc. Similarly, with A' and E' respectively 
d representing point of origin and destination, then alternate paths of travel could be 

represented as A'-B'-C'-D'-E' and A'-I'-H'-F'-E'. Rate of travel sensors (SI, S2, etc.) 
in one direction, based on such technology positioned along each of the route segments 
throughout the entire grid. 

The individual sensors are interconnected with the central computer 12 so that 
5 central computer 12 has continuing access to instant rates of travel for all of the route 
segments in the grid. The central computer, using an appropriate algorithm, may 
calculate and transmit information of the shortest elapsed time routes for origin- 
destination combinations to respective users. 

The pedagogical insight provided by the teachings and suggestions of Peterson 
10 with respect to the operation of a conventional cellular system and the delivery of elapsed 
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time information serve as another point of reference for the departure from the art in 
accordance with the subject matter of the present invention. 

As may now be readily appreciated from the foregoing discussion of the prior art, 
the prior art is devoid of teachings or suggestions for using geolocation data derived from 
5 movement of standard cellular telephones to automatically and dynamically generate up- 
to-date map databases. 

Moreover, once it is recognized that it is possible to automatically and dynamically 
generate map database data representative of the accessible highways and roadways, it is 
further contemplated that a map database containing such data can be used to address a 
10 myriad of highway traffic conditions and problems, as well as providing optimal guidance 
information to travel from a given source to a desired destination. For instance, there is a 
need to "reconcile" a vehicle's reported coordinate position against an existing map 
database of road location information to determine the location of the vehicle relative to 
the locations of known roads. 

15 SUMMARY OF THE INVENTION 

Shortcomings and limitations of the prior art are obviated, in accordance with the 
present invention, by methodologies and concomitant circuitry wherein, generally, 
geolocation data, map database information, and processing techniques effect the 
generation and use of the map database, especially to provide custom travel-related 
20 information. 

Broadly, in accordance with one aspect of the present invention, a system for 
generating map database information from the movement of vehicles includes: (i) a source 
of vehicle geolocation data obtained by passively geolocating at least one of the vehicles 
carrying a mobile transmitter; and (ii) a processor for processing the vehicle geolocation 
25 data by applying a prescribed algorithm to select a tracking sequence representative of at J 
least two reported positions of at least one of the vehicles, and then to estimate the U 
location of at least one road segment to thereby generate the map database information. 'J 
Moreover, in another embodiment, the processor further includes reconciliation means for 
reconciling the tracking sequence with road location data stored in a map database. In 
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addition, the processor further includes estimation means for estimating a travel path of a 
vehicle along one or more road segments corresponding to the tracking sequence. 

Broadly, in accordance with another aspect of the present invention, a system for 
providing custom travel-related information to a vehicle is cooperatively arranged with a 

5 map database of location-sensitive information relevant to one or more geographic areas. 
The system includes: (i) a geolocator for passively geolocating the mobile transmitter, (ii) 
a selector for selecting travel-related information from the map database by applying a 
selection algorithm based on a reported location of the vehicle to produce the custom 
travel-related information, and (iii) a delivery system for delivering the custom travel- 

10 information to the mobile receiver. 

Broadly, in accordance with yet another aspect of the present invention, a system 
for providing custom travel-related information to a remotely located user is arranged 
cooperatively with a map database of location-sensitive information relevant to one or 
more geographic areas. The system includes: (i) a selector for selecting travel-related 

15 information from the map database by applying a selection algorithm based on one or 
more locations to produce the selected travel-related information, and (ii) a delivery 
system for delivering the selected travel-information to the user at the remote location. 

Accordingly, the inventive subject matter provides a way to automatically generate , 
map database information and provide custom travel-related information to remote users, I 
20 either carried by a vehicle or not carried by a vehicle. In each aspect, the system is f 
centralized in the sense that it is operated at one or more central locations. 

The methodologies and concomitant circuitry exploit certain capabilities of cellulai 
phones and other mobile transmitters and receivers, namely: (1) the ability to passively 
geolocate a vehicle from the KF transmissions and communications of its cellular phone 

25 or other mobile transmitter; (2) the ability to transmit information from a vehicle to the 

central system using the vehicle's cellular phone or radio transmitter; and (3) the ability to 
transmit information from the centralized system to a vehicle using the vehicle's cellular 
phone or radio receiver. These capabilities, working together, create the ability to collect 
and deliver useful travel information without relying on additional special geolocation or 

30 communications equipment in the vehicle. 
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The use of passive geolocation of a vehicle's cellular phone or other mobile 
transmitter, as opposed to other means for vehicle geolocation, provides some special 
features, namely: 

(1) generally, the vehicle is not required to carry any special equipment other than 
5 an ordinary cellular phone, which many vehicles already carry; 

(2) the generated map database information reflects roads that are actually used, as 
opposed to roads that may physically exist but are closed to traffic; 

(3) the generated map database information can automatically reflect current roads, 
as opposed to roads that no longer exist or do not yet exist, because the information can 

10 be generated from current vehicle travel patterns; 

(4) systematic geolocation errors that occur in generating the map database may be 
self-canceling when the map database is later used in determining a vehicle's location. For 
example, if vehicle locations are incorrectly but consistently reported on a certain road 
segment, a map database may be produced that incorrectly indicates the position of that 

15 road segment. However, when a vehicle on that same road segment is later geolocated, if 
the geolocation error is consistent, then the vehicle's reported location will still correctly 
indicate the road segment on which said vehicle is traveling; 

(5) the resulting map database can automatically indicate the direction of travel of 
each road segment, in contrast with satellite photo or other physically-based maps; 

20 (6) the resulting map database can reflect either current or historic travel time 

information for each road segment, or both; and 

(7) the travel time information is based on measurements of vehicles' actual travel 
times, rather than assumptions based on speed limits and distances. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 The teachings of the present invention can be readily understood by considering 

the following detailed description in conjunction with the accompanying drawings, in 
which: 

FIG. 1 depicts a prior art cellular grid in which a cellular phone system is 
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deployed; 


FIG. 2 depicts a prior art cellular system for transceiving and cell hand-off; 
FIG. 3 depicts a prior art cellular system for passively geolocating mobile 
telephones; 


FIG. 5 depicts a prior ait cellular system for sensing vehicle movement and for 


FIG. 6 depicts a high-level block diagram of the geolocation system, processing 


FIG. 7 shows a Vehicle traveling along a roadway, a reported VehicleLocation 
position, and a RadiusOf Accuracy pertaining to the VehicleLocation position; 

FIG. 8 shows a Vehicle traveling along a road and several VehicleLocation 
positions from a TrackingSequence; 

FIG. 9 is a flow diagram for an illustrative ProcessingAlgorithm; 

FIG. 10 and FIG. 1 1 each show a TrackingSequence represented by a series of 
connected positions through which a Vehicle has traveled; 

FIG. 12 is a composite of the TrackingSequences of FIG. 10 and FIG. 11; 

FIG. 13 depicts the results of overlaying numerous TrackingSequences, including 
the TrackingSequences of FIG. 10 and FIG. 1 1 ; 

FIG. 14 shows smoothed VehicleLocation positions derived from the reported 
positions of FIG. 9 by weighted average; 

FIG. 15 shows successive VehicleLocation positions obtained by discarding some 
internal records; 

FIG. 16 shows a cluster of VehicleLocation points in close proximity; 

FIG. 17 depicts the VehicleLocation points of FIG. 16 after points in close 
proximity are eliminated; 


5 


FIG. 4 depicts a directed graph of nodes and links; 


providing elapsed travel time information to individual users; 


system, and map system in accordance with the present invention; 
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FIG. 18 illustrates a directed graph representation obtained from VehicleLocation 
data of FIG. 17; 

FIG. 19 shows a road link, a reported VehicleLocation position, and a 
corresponding RoadPosition; 

5 FIG. 20 shows the result of dividing the link of FIG. 19 into two links using a 

reported VehicleLocation; 

FIG. 21 shows an alternative to FIG. 20 wherein a link of FIG. 19 is divided into 
two links, each connected to a node coinciding with the VehicleLocation; 

FIG. 22 shows an exemplary directed graph containing RoadPositions 
10 corresponding to a TrackingSequence, as well as one TravelPath; 

FIG. 23 shows the same directed graph with an alternative TravelPath; 

FIG. 24 shows the reconciliation of ambiguous RoadPosition data; 

FIG. 25 shows a technique for partitioning a travel time over road links using an 
expected travel time for each of the road links as a weight in partitioning the travel time; 

15 FIG. 26 shows several road links with expected link travel time; 

FIG. 27 shows the road links of FIG. 26 along with Road Positions corresponding 
to VehicleLocations in a TrackingSequence; 

FIG. 28 shows the road links of FIG. 26 and the result of splitting the road links 
according to expected travel times; 

20 FIG. 29 shows the results of recombining the road links of FIG. 28 into the 

original road links from FIG. 26; 

FIG. 30 shows a hypothetical TrackingSequence following the path of an airplane 
that flies across two roadways; 

FIG. 31 shows a hypothetical TrackingSequence following the path of an off-road 
25 vehicle that drives off of a roadway; 

FIG. 32 shows a series of road links, in bold, representing a road, and a number 
of observed TrackingSequences representing travel along the road; 
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FIG. 33 depicts the road links of FIG. 32 after adjusting their positions to better 
match the average positions of the observed TrackingSequences. 

FIG. 34 depicts road links, in bold, representing a road's physical location, as 
determined from aerial photography, with the dashed lines representing a logical road 
5 location as estimated from geolocation data reported by the Geolocator; 

FIG. 35 shows an alternative representation for VehicleLocation positions as node 
names within a directed graph; 

FIG. 36 depicts a high-level block diagram of a geolocation system, map system, 
a selection processor, and guidance system in accordance with another aspect of the 
10 present invention; 

FIG. 37 is a flow diagram for an illustrative embodiment of a SelectionAlgorithm; 

FIG. 38 depicts the estimation of the direction or anticipated future path of a 
Vehicle using the Vehicle's current and previous road positions; 

FIG. 39 depicts the use of a stored profile history of a Vehicle's route; 
15 FIG. 40 depicts a high-level block diagram of a map system, a selection processor, 

and a guidance system in accordance with still another aspect of the present invention; 

To facilitate understanding, identical reference numerals have been used, where 
possible, to designate identical elements that are common to the figures. 

DETAILED DESCRIPTION 

20 After considering the following description, those skilled in the ait will clearly 

realize that the teachings of my invention can be readily utilized to generate location- 
sensitive map database information, and that such information can be stored in a database. 
Moreover, those skilled in the art will readily appreciate that, once such a map database 
of location-sensitive information is produced, by these or other methods, it is feasible to 

25 deliver custom travel-related information to a Vehicle. In addition, the map database may 
be used to provide custom travel-related information to a third party. Finally, it is readily 
contemplated from the above description that the techniques engender the very creation of 
a map database. 
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By way of terminology, in this description, the terms "road" , "roadway" , "street" , 
or "highway" are intended to indicate any designated public or private road, street, 
highway, freeway, thoroughfare or other passageway on which a vehicle is intended to 
travel. Furthermore, although this description frequently refers to "travel times", it 
5 should be understood to also cover any implementation that instead uses a simple 

encoding from which such travel time information can be easily derived - for example, 
by representing travel speed over a known distance. 
FIRST MAJOR F T^ODTMPNT: 

GENERATING MAP DATABASE INFORMATION 
10 The description is this section commences with an elucidation of an illustrative 

embodiment that automatically generates location-sensitive map database information. 
More complex embodiments that provide other capabilities follow in the sequel. 

With reference to FIG. 6, system 100 is composed of the following components: 
(a) source 101 of vehicle geolocation data, referred to as the Geolocator, (b) map database 
15 information storage device 102, referred to as the MapDatabase; and (c) interposed 

processor 103, referred to as the Processing Algorithm. (Although these components are 
set forth as discrete elements for discussion purposes, it will be readily appreciated that 
one or more elements may be merged into a single component; for example, storage 
device 102 and processor 103 may be only one physical component, such as a computer, 
20 performing the functionality desired of storage device 102 and processor 103.) 

It is initially presumed, by way of concreteness but without loss of generality, that 
the vehicle geolocation data is provided in real time by passively geolocating at least one 
vehicle 104 carrying a mobile transmitter. System 100 operates by receiving geolocation 
data from the Geolocator 101 and applying the ProcessingAlgorithm 103 to the received 
25 data, in conjunction with map database data supplied by MapDatabase 102. 

To fully elucidate the operation of system 100, each system element and the 
interaction of each element with the other elements are now described in more detail. 

The Geolocator is responsible for providing tracking data on the locations of a 
vehicle ("Vehicle"), determined at different times by passively geolocating the Vehicle's 
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mobile transmitter. A "tracking interval" is the period of time during which the Vehicle's 
location is tracked. Use of passive geolocation of a Vehicle's mobile transmitter, as 
opposed to other techniques of vehicle geolocation, provides some special benefits that 
will be appreciated later. 

5 For generating location-sensitive map database information, the Geolocator must 

provide sufficient location data to indicate a sequence of at least two locations through 
which a Vehicle has traveled during the tracking interval. Each Vehicle location datum 
("VehicleLocation") indicates or implies the instantaneous position of the Vehicle. The 
position may be represented by a point position, but it could be represented in other ways 

10 also. For example, a position could be represented by an area (a circle, rectangle or some 
other area designation) in which the Vehicle was estimated to be located at the time of 
geolocation. 

In addition to indicating a Vehicle's position, a VehicleLocation may also be 
considered to include additional information such as the absolute or relative time at which 

15 the Vehicle was geolocated ("TimeStamp"), a measure of how accurate the reported 
position is thought to be, or a code that identifies the Vehicle that was tracked 
("VehiclelD"). The VehiclelD could be the Vehicle's cellular phone number, for 
example. However, for privacy reasons it may be preferable to use an arbitrarily 
assigned code. The measure of accuracy might be a radius of accuracy 

20 ("RadiusOfAccuracy"), for example. With reference to FIG. 7, there is shown Vehicle 
108, traveling along a roadway 109, a reported VehicleLocation position 110 of Vehicle 
108, and a RadiusOfAccuracy 111 pertaining to VehicleLocation position 110. 

A "TrackingSequence" is a collection of two or more time-ordered 
VehicleLocation records pertaining to one Vehicle during one tracking interval. The time 
25 ordering of the VehicleLocation records may be indicated by the order in which the 
VehicleLocation records are delivered, by a Time Stamp associated with each 
VehicleLocation record, or by any other means sufficient to indicate a time ordering 
among the records. 

The Geolocator must provide VehicleLocation data suitable for tracking at least 
30 one Vehicle through at least two VehicleLocations. However, in a preferred 
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embodiment, the Geolocator could provide VehicleLocation data on more than one 
Vehicle, in which case the Geolocator must provide sufficient information to allow the 
ProcessingAlgorithm to distinguish between the VehicleLocation records of different 
TrackingSequences. The way this is accomplished is immaterial to system 100. 
However, one way it could be done is to include a unique TrackingSequence identifying 
code with each VehicleLocation record. This identifying code could be derived from the 
VehiclelD, for example. 

Table 1 shows several possible VehicleLocation records. Each row in Table 1 
represents a VehicleLocation record, including a VehiclelD, a position (e.g., x,y 
coordinate) and a TimeStamp. 

Table 2 shows the same VehicleLocation records as Table 1, but the rows of Table 
2 have been sorted by VehiclelD, so that the VehicleLocation records for VehiclelD 
12023861234 are grouped together as a TrackingSequence, and the VehicleLocation 
records for VehiclelD 13017729988 are also grouped together as another 
TrackingSequence. 

Although different TrackingSequences may pertain to different vehicles, different 
TrackingSequences may also be obtained from tracking the same Vehicle during different 
tracking intervals. 

The Geolocator may either provide real-time or non-real-time VehicleLocation 
data. In one embodiment, the Geolocator provides real-time VehicleLocation data to the 
MapDatabase. (For example, the Geolocator may periodically report the VehicleLocation 
of one or more vehicles.) From the data produced by the Geolocator, the 
ProcessingAlgorithm can select a TrackingSequence for a Vehicle, such as by re-ordering 
the data according to the TimeStamp, as illustrated in Table 3. 

By plotting and connecting the sequence of positions indicated in the 
TrackingSequence, the approximate travel path of the Vehicle emerges, as illustrated in 
FIG. 8. If the Vehicle's travel was along roads, and the TrackingSequence contains 
sufficiently frequent and accurate VehicleLocation data, then this travel path indicates the 
approximate positions of the roads on which the Vehicle has traveled. FIG. 8 shows 
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vehicle 112 traveling along a road 113, and several VehicleLocation positions 114a-k 
from the TrackingSequence of Table 3 . 

The ProcessingAlgorithm is illustrated in the flow chart of FIG. 9. The 
ProcessingAlgorithm begins at Start block 901 and inputs VehicleLocation data from the 

5 Geolocator via processing block 902, selects one or more TrackingSequences via 

processing block 903, optionally processes them further in block 904, as discussed later, 
and either outputs or stores the results as indicated by processing block 905. The end of 
processing is indicated by Done block 906. In one embodiment, the ProcessingAlgorithm 
may output the result of its computations for use by external devices or storage in an 

io external database. In another embodiment, the ProcessingAlgorithm may store the result 
of its computations in a location-sensitive information database that is a part of system 
100, for example, in MapDatabase 102 of FIG. 6. In one embodiment (not shown in 
FIG. 6), system 100 could also provide access to the MapDatabase for use by other 
devices or users at remote locations. 

15 in general, VehicleLocation data coming from the Geolocator 101 will represent 

data for multiple TrackingSequences. Individually, each TrackingSequence represents a 
series of connected positions through which the Vehicle has traveled, as depicted visually 
in FIG. 10 and FIG. 11. FIG. 10 shows a TrackingSequence 116 comprising many 
VehicleLocation positions, a few of which are labeled as VehicleLocation positions 1 15a- 

20 d. FIG. 11 shows another TrackingSequence 117 comprising many VehicleLocation 
positions that are not individually labeled in FIG. 11. 

When multiple TrackingSequences are accumulated and considered together, a 
composite map is obtained, as depicted visually in FIG. 12, which is a composite of FIG. 
10 and FIG. 11, that is, FIG. 12 shows TrackingSequence 116 and TrackingSequence 

25 1 17 plotted together. 

If the Geolocator produces sufficiently frequent, precise and accurate 
VehicleLocation data, and if a sufficient number of TrackingSequences are accumulated, 
a rough map of the area's roads emerges, as illustrated in FIG. 13, which shows several 
TrackingSequences plotted together, including TrackingSequence 116. 
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By selecting TrackingSequences from the VehicleLocation data produced by the 
Geolocator 101, system 100 has generated map database information independent of any 
pre-existing information, such as map database data with roads and road names. The map 
database information may either be stored as a stand-alone database, or outputted to 
5 another device for deployment. 

I. Variations of the First Maior Em bodiment 

There are many possible variations of system 100 described above that can be 
implemented by adding additional functions, as performed via processing block 904 of 
FIG. 9, to the ProcessingAlgorithm. Such functions can be applied individually or in 
10 various combinations. Several possible additional functions that the ProcessingAlgorithm 
might perform are now described. 
A > DATA SMOOTHING: 

One additional function the ProcessingAlgorithm might perform would be data 
smoothing on the VehicleLocation data for each TrackingSequence. Data smoothing is not 
15 necessarily desirable if other data massaging techniques will also be applied, because it 
necessarily involves a loss of information, but it can be helpful in obtaining a more 
visually understandable plot of the resulting VehicleLocation data. 

To perform data smoothing, a prescribed algorithm can be applied to identify and 
correct for seemingly random variations in the VehicleLocation data. For example, for 
20 each pair of successive positions in a TrackingSequence, a new position could be 

computed as a weighted average of the successive positions and the original position. 

Other methods of smoothing could be used instead. FIG. 14 shows smoothed 
positions 118a-k, which were derived from reported positions 114a-k of FIG. 8 by 
weighted average. FIG. 14 also shows Vehicle 112 and road 113. 

25 B.) rONSOT TDATTON OF DATA: 

Another function the ProcessingAlgorithm could perform is to consolidate 
VehicleLocation data. A prescribed algorithm can be applied to reduce the number of 
VehicleLocation records in a TrackingSequence. For example, successive 
VehicleLocation records whose positions are in a sufficiently straight line could be 
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consolidated by discarding some internal records, as illustrated in FIG. 15. Table 5 
shows the VehicleLocation records from Table 4, with records 2, 5, 7 and 10, 
representing positions 118b, 118e, 118g and 118j, shown shaded to indicate that they 
have been selected for deletion. Table 6 shows the result of deleting records 2, 5, 7 and 
5 10, representing positions 118b, 118e, 118g and 118j, from Table 5. The 

VehicleLocation records of Table 6 are shown in FIG. 15, which shows Vehicle 112 on 
road 113 and remaining VehicleLocation positions 118a, 118c, 118d, 118f, 118h, 118i 
and 118k. 

r > rnxrertT TDATTON OF SUB-SEQUENCES : 

10 Another function the ProcessingAlgorithm can perform is to apply a prescribed 

algorithm to consolidate a sub-sequence of VehicleLocation records whose positions are 
sufficiently close together. This typically occurs when a Vehicle is stopped. For 
example, in Table 7, records 7-27 form a cluster of points in close proximity. 

The points of Table 7 are illustrated in FIG. 16, which shows a cluster 120 of 
15 points in close proximity, corresponding to records 7-27 of Table 7. 

One way to consolidate a sub-sequence of VehicleLocation records whose 
positions are sufficiently close together is to discard some of them. For example, each 
successive point in a TrackingSequence that is within some radius of the previous retained 
point is discarded. Table 8 shows the VehicleLocation records remaining after deleting 
20 rows 2, 3, 5, 7-27, 29, 30, 32 and 33 from Table 7. 

FIG. 17 shows the VehicleLocation positions of Table 8. FIG. 16 and FIG. 17 
also show the VehicleLocation positions 119a-f that were not discarded in this process. 

D.) CONVERSION TO A DI RECTED GRAPH: 

Another function the ProcessingAlgorithm can perform is the conversion of the 
25 VehicleLocation data into a directed graph representation. FIG. 18 illustrates a directed 
graph representation of the data from Table 8. FIG. 18 shows nodes 121a-f, 
corresponding respectively to points 119a-f of FIG. 17. FIG. 18 also shows links 122a-e 
connecting nodes 121a-f. 
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For the purposes of this discussion, assume that the graph is represented as a list 
of nodes and a list of links. However, it should be apparent to one skilled in the art that 
there are several well-known ways to represent a graph, and the specific representation is 
not an essential aspect of system 100. 

5 Table 9 shows a list of nodes for FIG. 18. Each row in Table 9 is derived from 

the corresponding VehicleLocation in Table 8, and represents one node. 

Table 10 shows a list of links for FIG. 18. Each row in Table 10 represents one 
link, connecting from the FromNode to the ToNode. A link was generated for each pair 
of adjacent VehicleLocation records within a TrackingSequence. The direction of the link 
10 from the FromNode to the ToNode indicates the direction in which the Vehicle traveled, 
as indicated by the ordering of the VehicleLocation records in the TrackingSequence. 

Table 10 also shows the TravelTime for each link, which is the difference between 
the TimeS tamps of the VehicleLocation records corresponding to the FromNode and 
ToNode of the link. This TravelTime data is useful for services that compute the fastest 
15 route from a source location to a destination location, for example. 

These discussions have demonstrated how the ProcessingAlgorithm can perform 
additional functions to produce more useful data from selected TrackingSequences, and, 
in particular how the ProcessingAlgorithm can convert TrackingSequence data into data 
representing a directed graph. 

20 n. Reconciling VehicleLocation Data Against an Existing Map Database 

Another function the ProcessingAlgorithm might perform is that of reconciling 
new VehicleLocation data against an existing map database of known roads — in other 
words, to determine the relationship between a Vehicle^ reported position(s) and the 
locations of known roads. The primary purposes of this reconciliation are to determine 
25 the Vehicle's instantaneous position on a road segment, and/or to determine the Vehicle's 
travel path along one or more road segments. 

The process of reconciliation requires a map database. Such a database could be 
externally supplied, or in another embodiment it could be a map database that was 
generated by system 100. In fact, in a preferred embodiment, such a database could be 
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automatically updated continuously by system 100. For simplicity, it is assumed that the 
map database data is represented by a directed graph, i.e., a set of nodes and directed 
links in which each link represents a road segment or "road link". However, other 
representations are possible also. 

5 One purpose of reconciling a VehicleLocation datum against an existing map 

database is to estimate the position, along a road link, that corresponds to the 
VehicleLocation that was reported by the Geolocator. A position along a road link in the 
graph is called a "RoadPosition" . If each road segment is represented as a sequence of 
one or more connected links in a graph, then for convenience, a RoadPosition can be 

10 represented as an additional node that divides a link (the "original link") into two links 
(the "new links") at an appropriately interpolated location that represents a position along 
the corresponding road segment. The interpolated location for the new node can be 
selected using a prescribed algorithm incorporating trigonometric formulas. For example, 
select the new node position as the position on a straight line, leading from the FromNode 

15 to the ToNode, that is closest to the VehicleLocation position for which a RoadPosition is 
to be selected. In addition, if the original link had a travel time associated with it, then 
the travel time could be divided between the two new links using an appropriate formula. 
For example, the travel time could be prorated according to the travel distance that each 
of the new links represents. 

20 FIG. 19 shows a road link 124 from node 123a to node 123b; a reported 

VehicleLocation position 125; and a corresponding RoadPosition 126. 

FIG. 20 shows the result of dividing link 124 of FIG. 19 into two links, link 127a 
and link 127b. Links 127a and 127b have replaced the previous link 124. 
VehicleLocation position 125 is shown in FIG. 20. FIG. 20 also shows a new node 123c, 

25 which represents RoadPosition 126 corresponding to VehicleLocation position 125. 

If it is assumed, for example, that the TravelTime for link 124 is 10 minutes, and 
the distance from node 123a to node 123b is 10 miles, and the distance from node 123a to 
node 123c is 4 miles, and the distance from node 123c to node 123b is 6 miles; then 
assign a prorated TravelTime of 4 minutes to link 127a and a prorated TravelTime of 6 
30 minutes to link 127b. In other words, when link 124 is split into links 127a and 127b, the 
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TravelTime of link 124 is distributed among links 127a and 127b. 

Another way to select the new node position for the RoadPosition corresponding to 
VehicleLocation position 125 is to directly use the reported VehicleLocation position, as 
illustrated in FIG. 21, which shows a new node 123d that is coincident with 
VehicleLocation position 125. In FIG. 21 two new links, link 128a and link 128b, 
replace previous link 124 of FIG. 19. FIG. 21 also shows existing nodes 123a and 123b, 
which are unchanged from FIG. 19. Other techniques of selecting a new node position, 
such as interpolating a position along a spline curve, are also possible. 

To avoid generating an excessive number of links, adjacent links can be combined, 
provided that the node that connects said links does not also connect any other links that 
need to be retained. For example, if said links are in a sufficiently straight line and 
represent sufficiently similar travel speeds, then it may be desirable to combine them. To 
do so, the travel times of said links can be added to produce a travel time for a new 
replacement link. This is essentially the reverse of the process for splitting a link. For 
example, assume that in FIG. 20 the TravelTime for link 127a is 4 minutes and the 
TravelTime link 127b is 6 minutes, then replace links 127a and 127b with link 124 (FIG. 
19), assigning a TravelTime of 10 minutes (the sum of the TravelTimes of links 127a and 
127b) to link 124. 

From a sequence of RoadPositions, the Vehicle's "TravelPath" can be constructed, 
namely, a sequence of road links indicating the presumed movement of the Vehicle along 
the corresponding roads. This is illustrated in FIG. 22. FIG. 22 shows a directed graph 
of nodes 129a-h and links 130a-h. Nodes 129a, 129b, 129c and 129d represent a 
sequence of RoadPositions corresponding to a TrackingSequence. FIG. 22 shows one 
possible TravelPath as the sequence of links 130a, 130b and 130c. 

FIG. 23 again shows a directed graph of nodes 129a-h and links 130a-h. Nodes 
129a, 129b, 129c and 129d again represent a sequence of RoadPositions corresponding to 
a TrackingSequence. However, FIG. 23 shows another possible TravelPath, comprising 
the sequence of links 130a, 130d, 130e, 130f, 130h and 130c. 

A TravelPath can be selected from a sequence of RoadPositions by applying an 
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algorithm to estimate the most likely route from each RoadPosition to the next. For 
example, the most likely route might be assumed to be the fastest or shortest known 
route. With the map database represented as a directed graph of links and nodes, the 
fastest or shortest route can be readily computed using any of several well-known shortest 
5 path algorithms. However, depending on the graph and the frequency of VehicleLocation 
data, there might be only one non-repetitive path from a given RoadPosition to the next. 
For example, in the directed graph of FIG. 23, there is only one path from node 129f to 
node 129h, and that is the path comprising links 130f and 130g. 

In some cases, a Vehicle's RoadPosition (as indicated by a VehicleLocation) may 
io be ambiguous: more than one road segment may apply to the same position. This can 
happen, for example, if one road on a bridge crosses above another road without 
connecting. However, this can also happen if different road segments are within the 
RadiusOf Accuracy or area that is reported for the Vehicle's position, as illustrated in 
FIG. 24. FIG. 24 shows two VehicleLocation positions 136a and 136b in sequence, 
15 each with a RadiusOfAccuracy 137a and 137b, and corresponding RoadPositions 138a 
and 138b (as determined later), respectively. Road links 140a-h connect nodes 139a-i. 
RoadPositions 138a and 138b are coincident with nodes 139h and 138i, respectively. In 
this case, the RoadPosition of VehicleLocation 136a is ambiguous because 
RadiusOfAccuracy 137a includes three road segments: road links 140a, 140d and 140e. 
20 Similarly, the RoadPosition of VehicleLocation position 136b is ambiguous because 

RadiusOfAccuracy 137b includes five road segments: road links 140a, 140b, 140c, 140h 
and 140d. 

(As an aside, although each node in a directed graph represents a single idealized 
position, more than one node can occupy the same position without being connected. 
25 This could occur, for example, if one node were representing a position on a road on a 
bridge, and another node were representing the same two-dimensional position on a road 
crossing under the bridge. There are also other circumstances in which this can occur.) 

Ambiguous RoadPosition data could be ignored, or sometimes it can be 
disambiguated by other means, such as by examining one or more previous 
30 VehicleLocations in the Trackings equence, as was illustrated in FIG. 24, to select the 
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most likely RoadPosition from among more than one current candidate. This can be done 
by estimating the likelihood of the TravelPath implied by the sequence of RoadPositions 
or VehicleLocations through which the Vehicle has traveled. 

As a Vehicle's TravelPath becomes known, this TravelPath information can be 

5 used to record traffic or travel time information for the road links indicated in the 

TravelPath. For example, a count of the number of Vehicles observed traversing each 
link during some specified interval can be retained. This could be used, for example, to 
automatically collect tolls or measure traffic flow. It can also be used to decide whether a 
hypothesized new road segment is valid, as discussed later. 

10 Another use of a Vehicle's TravelPath is to store a history of the Vehicle's travel 

routes, for use later. This could include, for example, a profile of a user's usual routes to 
work and home. This could be done automatically by recording the TravelPath of the 
Vehicle, over a period of days for example, or it could be done at the user's request. 

In short, the process of reconciling VehicleLocation data against an existing map 

15 database can allow this system to determine the TravelPath of a Vehicle along known road 
segments. 

m. Collecting Travel Time Information 

One important use of a Vehicle's TravelPath is to record travel time information 
for specific road links. Travel time data for the road links in a Vehicle's TravelPath can 
20 be estimated by applying a prescribed algorithm or mathematical formula to prorate, 
among the road links, the travel times that are indicated by the associated 
TrackingSequence. The travel times between RoadPositions corresponding to 
VehicleLocations in a TrackingSequence need not correspond directly to consecutive 
nodes in the Vehicle's TravelPath, because, as previously noted, links along a path can be 
25 split or combined as needed. 

For example, if two successive VehicleLocations in a TrackingSequence are far 
enough apart that they imply a TravelPath containing several road links, as illustrated in 
FIG. 25, and the travel time between said VehicleLocations was measured as t, then the 
travel time t can be divided among said road links. One way to do this is to use an 
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expected travel time for each of the road links as a weight in dividing up travel time t, as 
illustrated in FIG. 25. The expected travel time for a road link may be computed using 
previously recorded travel times, an assumed speed limit for the road segment, or other 
means. Other algorithms or formulas could also be used to divide travel time t among 
S said road links. 

FIG. 25 shows road links 141a-e connecting nodes 142a-f. Each road link is 
labeled with its expected travel time, weight, and a prorated measured travel time, as set 
forth in Table 11. 

On the other hand, if VehicleLocations in a TrackingSequence are close enough 
10 together that two successive VehicleLocations imply a path that is shorter than a single 
road link, then VehicleLocations in said TrackingSequence can be consolidated as 
necessary, as previously discussed. The following example illustrates this process, 
showing how closely-spaced VehicleLocation data can still be used to measure travel 
times for specific road segments. 
15 FIG. 26 shows three road links 132a-c connecting nodes 131a-d. Each link is 

further labeled with an expected link travel time. 

FIG. 27 again shows road links 132a-c connecting nodes 131a-d, but also shows a 
sequence of RoadPositions 133a-d corresponding to VehicleLocations in a 
TrackingSequence. Each RoadPosition is further labeled with a TimeStamp so that the 
20 travel time between RoadPositions can be computed. 

FIG. 28 again shows nodes 131a-d, but road links 132a-c of FIG. 27 have been 
split into road links 134a-g in FIG. 28, using additional nodes 135a-d corresponding to 
RoadPositions 133a-d of FIG. 39. In FIG. 28, road links 134a-g are further labeled with 
expected travel times derived from the original expected travel times of road links 132a-c 
25 of FIG. 27. In FIG. 28, road links 134b-f are also labeled with the prorated measured 
travel times computed by prorating the travel times between RoadPosition nodes 135a-d. 
(Since the measured travel time between RoadPosition nodes 135b and 135c did not need 
to be prorated, its "Prorated measured travel time", as indicated in FIG. 28, is actually its 
measured travel time.) 
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FIG. 29 shows the result of recombining road links 134a-g of FIG. 28 back into 
original road links 132a-c. The prorated measured travel times of road links 134c-e of 
FIG. 28 have been combined to produce the resulting prorated measured travel time of 
road link 132b in FIG. 28. In FIG. 28, road links 132a-c connect nodes 131a-d, just as 
5 in FIG. 26, but we have now computed a measured travel time for road link 132b from a 
sequence of RoadPositions corresponding to VehicleLocation data in a TrackingSequence. 

Having collected travel time information for specific road segments as just 
described, system 100 could output the resulting information or store such information in 
a database. In a preferred embodiment, such information would be stored in 
10 MapDatabase 102 of FIG. 6. 

!V. Collecting Historic Travel Time Dat a to Model Travel Conditions 

The preceding section has illustrated how VehicleLocation data from the 
Geolocator can be used to measure travel times for specific road segments. By 
accumulating travel time data for specific road segments, statistical means can be used to 
15 develop models of travel conditions, which can be used to predict current travel times in 
the absence of real-time data, or to predict future travel times -- for example, by 
computing an average travel time over a given road link at different times throughout a 
typical weekday we can predict the travel time required to traverse said road link on a 
future weekday. 

20 Table 12 shows hypothetical average travel times for a specific road link during 

several different times of a typical weekday morning. 

Historic data could be used to generate travel time models that reflect rush hours, 
weekend traffic changes, holiday travel conditions, good or bad weather traffic 
conditions, seasonal traffic differences, and other factors that have a statistically 

25 significant effect on travel times. 

In general, we can use historic travel time data to develop a road link travel time 
prediction function, ExpectedLirdcTravelTime(linkTO,timeAndDate), that computes the 
expected travel time required to traverse road link linklD at any particular time 
timeAndDate. (In this description, any mention of a particular time should be assumed to 
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include or imply a date also, if necessary.) 

This ExpectedLinkTravelTime function can be used by the ProcessingAlgorithm 
and updated dynamically as new data is received from the Geolocator or other sources. 
Furthermore, this function could also be programmed to make use of externally-supplied 
5 information on other scheduled or unscheduled events that may affect travel times, such 
as road construction, a big concert ending, or a road closure for a parade. For example, 
a road closure can be represented by a very high travel time, i.e. , a travel time that 
surpasses the expected road re-opening time. 

One simple way to implement the ExpectedLinkTravelTime function would be to 
io employ, for each road link, a base table of average weekday travel times, as previously 
illustrated in Table 12. Other tables could be used to apply adjustments for travel-time- 
affecting factors, such as bad weather or weekend travel. Table 13 illustrates a 
hypothetical table of rainy weather adjustments. 

Of course, many other statistical techniques can be used to develop function 
15 ExpectedLinkTravelTime, and there are many other ways such a function could be 

implemented. The exact implementation of function ExpectedLinkTravelTime is not an 
essential aspect of this system. 

Finally, the timeAndDate parameter of the ExpectedLinkTravelTime function 
might either represent the time when the Vehicle leaves the link's FromNode, or the time 
20 when the Vehicle arrives at the link' s ToNode, or some average thereof. If the system 
that uses the resulting graph needs to estimate an arrival time at a destination, given a 
source location and departure time, then the timeAndDate parameter might represent the 
time when the Vehicle leaves the link's FromNode. However, if the resulting graph will 
be used to estimate a departure time from a source location, necessary to arrive at a 
25 destination at a particular time, then the timeAndDate parameter could instead represent 
the time when the Vehicle arrives at the link's FromNode, so that the graph search 
algorithm can work backwards from the destination to the source location to estimate the 
necessary departure time, as will be discussed later. If both tasks need to be performed, 
then two different versions of the ExpectedLinkTravelTime function could be used. 
30 However, depending on the link times involved, and the required precision of the result, 
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it may be unnecessary to make this distinction, and a single ExpectedLinkTravelTime 
function may suffice. 

V. Excluding Unwanted Travel Time Data 

Another function of the ProcessingAlgorithm might be to exclude anomalous or 
inapplicable data. For example, the system could ignore travel times pertaining to 
Vehicles that have stopped for lunch. 

This can be done by comparing the travel times associated with the TravelPaths of 
different Vehicles traversing the same road links during the same period, and excluding 
travel times that are unusually high. For example, the ProcessingAlgorithm could select 
the median travel time measured for each road link, for use as the most representative 
travel time pertaining to said link, thus excluding anomalous times. Or the 
ProcessingAlgorithm might discard the highest 10%, for example, of measured travel 
times. Or the ProcessingAlgorithm might discard any travel time that is more than 5 
minutes greater than the median of the measured travel times, for example. Other 
thresholds could also be used, and many other data exclusion policies are possible also. 

If the data exclusion policy excludes data from involuntary Vehicle stoppages, 
such as a Vehicle stopping at a traffic signal, then the resulting travel time data will be 
optimistically biased. To avoid such bias, it may be desirable to use data exclusion 
parameters that are liberal enough to cause such data to be retained, but restrictive enough 
to exclude most voluntary stoppages. This can be achieved by adjusting such parameters 
higher or lower until the desired data exclusion effect is attained. 

VI. Determining the Name of a Road 

It has been demonstrated how the ProcessingAlgorithm can reconcile 
VehicleLocation information against a map database to generate useful travel time 
information for specific road segments. Some additional uses for reconciling 
VehicleLocation data against a map database are now described. 

One additional reason for reconciling VehicleLocation data against a map database 
is to determine the name of the road on which a Vehicle is traveling. If the existing map 
database contains road names associated with road links, a RoadPosition that is computed 
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in the reconciliation process could also be used to determine the road name that should be 
associated with the Vehicle's position. This reconciliation may be particularly useful in 
generating a new map database, containing travel time information and road names, from 
an existing map database that contains road names but does not contain measured travel 
time information. 

Vn. Excluding Non-Vehicular or Off- Koad Travel Data 

Another reason for reconciling the new VehicleLocation data against an existing 
map database of known roads might be to exclude data corresponding to non-vehicular or 
off-road travel, such as by an airplane or train carrying a cellular phone. There are 
various ways this can be done. For example, if the distance from a VehicleLocation 
position to the nearest known road is larger than the VehicleLocation' s RadiusOfAccuracy 
or an assumed margin of error, then infer that the data does not indicate a Vehicle 
traveling on a known road, and therefore the data may indicate an airplane or train or a 
person walking with a cellular phone, for example. 

Another technique for identifying non-vehicular travel is to estimate the likelihood 
of possible routes, via known roads, that connect RoadPositions that correspond to 
VehicleLocation data in a TrackingSequence. This can be done, for example, by 
computing the minimum travel time, via known roads, between said RoadPositions, and 
comparing said minimum travel time against the observed travel time. If the observed 
20 travel time implies an excessive speed, then the data could be excluded as anomalous or 
due to airplane travel, as illustrated in FIG. 30. Statistical measures or other methods can 
also be used to exclude anomalous or irrelevant data. FIG. 30 shows a hypothetical 
TrackingSequence 143 following the path of an airplane 145 that flies across two 
roadways 144a and 144b. 
5 If system 100 is being used to generate a new map database without the aid of an 

existing map database, or if it is being used to update an existing map database to reflect 
new road segments, then a non-vehicular travel path could initially be confused with a 
new road, as illustrated in FIG. 31. FIG. 31 shows a hypothetical TrackingSequence 146 
following the path of an off-road vehicle 148 that drives off of a roadway 147. 
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Tfais can be corrected using manual intervention. For example, each prospective 
new road segment could be automatically flagged, and manually confirmed or rejected 
later. Or the ProcessingAlgorithm could look for additional corroborating evidence 
before accepting the new path as a new road segment. For example, the 
5 ProcessingAlgorithm could look for other similar paths in the incoming VehicleLocation 
data. This can be done by initially assuming that each new path indicates a new road, and 
then counting how many other Vehicles appear to travel along this hypothesized new 
road. If enough other Vehicles appear to travel along this same hypothesized new road, 
then assume that this new road is valid. 

10 Vm. Using Geolocation Data to Adjust Node Positions 

Another function the ProcessingAlgorithm can perform is to adjust node positions 
to better match observed geolocation data. This can be done by applying curve fitting 
algorithms to compute node positions that minimize the deviation of the observed 
geolocation data from the new node positions, for Vehicles that have traversed said nodes. 

15 For example, FIG. 32 shows road links 149a-c connecting nodes 150a-d, and a 

cluster of hypothetical Trackings equences 151 representing observed travel that has 
traversed said road links. 

FIG. 33 shows the result of adjusting the positions of nodes 150a-d of FIG. 32 to 
better match the average positions of the observed geolocation data for these road links. 
20 FIG. 33 shows road links 152a-c connecting nodes 153a-d. (Road link 152b is very 

short, connecting node 153b to node 153c) Nodes 153a-d of FIG. 33 represent the result 
of adjusting the positions of nodes 150a-d, respectively, of FIG. 32 to more closely match 
the positions of TrackingSequences 15 1 . 

Even if a road is known to be in a certain physical location, it can be beneficial to 
25 determine a logical road location from geolocation data reported by the Geolocator. For 
example, in FIG. 34, the bold road links 154a-c may represent the road's idealized 
physical location (for one direction of travel), as determined from aerial photography, and 
the dashed links 156a-c may represent a logical road location as estimated from 
geolocation data reported by the Geolocator. This logical road location can be beneficial 
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to use in a map database, because if the same Geolocator is used with the map database in 
providing services, then the logical road location will more closely match the geolocation 
data produced by the Geolocator. For example, if the Geolocator tracks a Vehicle to 
provide route guidance, the VehicleLocation data reported by the Geolocator during 
5 tracking will more closely match the logical road location in the map database. In other 
words, systematic errors in the geolocation data reported by the Geolocator will tend to be 
self-canceling when the map database is used in conjunction with the same Geolocator. 
This is a special benefit of using the same Geolocator for both generating the map 
database and for providing location-based services that use the map database. 
l0 FIG. 34 shows solid road links 154a-c connecting solid nodes 155a-d, representing 

the physical location of road 158 (one direction). Dashed road links 156a-c connect 
hollow nodes 157a-d, representing a logical location of road 158 as determined from 
geolocation data. 
IX. Geolocator Variations 
15 There are a number of ways the Geolocator can determine and indicate the location 

of a Vehicle. In one implementation of the Geolocator, a Vehicle's location might be 
determined using Time Difference Of Arrival (TDOA) or Angle Of Arrival (AOA) of the 
Vehicle's RF transmissions. In another embodiment, the approximate location of the 
Vehicle could be determined by identifying the cell site to which the Vehicle's ceUular 
20 phone is currently assigned. This will often locate the Vehicle to within a few kilometers, 
but may not be accurate enough to determine the specific road on which the Vehicle is 
located. Many other embodiments of the Geolocator are possible also. 

In general, the precision of the data that is produced by system 100 will depend on 
the precision and accuracy of the VehicleLocation data provided by the Geolocator. For 
25 greatest usefulness, the Geolocator should produce sufficiently accurate geolocation data 
to allow system 100 to determine the road on which a Vehicle is traveling. However, this 
system can still generate useful long-distance travel time information even if the 
Geolocator is not accurate enough to distinguish individual roads. If the Geolocator is not 
accurate enough to distinguish individual roads, then each road link in the directed graph 
30 may represent a corridor, or group of roads in proximity, and each node may represent an 
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area. The resulting graph can be used to predict travel time from one area to another, for 
example. 

For purposes of the above description, we have assumed for simplicity (but 
without loss of generality) that the Geolocator provides real-time VehicIeLocation data. 
However, in another embodiment, the Geolocator could supply non-real-time 
VehicIeLocation data. For example, the Geolocator could store multiple VehicIeLocation 
records in a buffer or database and supply them to the MapDatabase as required at a later 
time, either singly or in groups. Or, in another embodiment, the Geolocator could 
contain or access an externally-supplied database of stored VehicleLocations. 

If the Geolocator provides non-real-time VehicIeLocation data, then the 
VehicIeLocation data must contain sufficient information to indicate the relative time 
orderings of a Vehicle's VehicIeLocation records, so that the ProcessingAlgorithm can 
select TrackingSequences. This may be accomplished by including a TimeStamp with 
each VehicIeLocation record, as illustrated in Table 3, but it could also be accomplished 
15 by indicating the sequence in which the VehicIeLocation records for a Vehicle should be 
interpreted, for example by indicating a record number for each VehicIeLocation record, 
as also illustrated in Table 3. Other well-known techniques for indicating an ordering 
among the records are possible also. 

Those skilled in the art will appreciate that the Geolocator is only assumed to be 
20 capable of providing sufficient VehicIeLocation data that was obtained by passively 

geolocating a Vehicle's cellular phone or other RF transmitter. It is immaterial to this 
system whether the Geolocator generates said VehicIeLocation data itself, receives the 
VehicIeLocation from a geolocation device external to this system, provides the 
VehicIeLocation data from a database that was created locally or remotely, or uses some 
25 other means to obtain the necessary data. 

x - Other Wavs to Repres ent a Vehicle Position 

For purposes of the above discussions, we have assumed that a VehicIeLocation 
position is represented either as a point or a point with a RadiusOf Accuracy. However, 
there are other ways a Vehicle's position can be represented. 
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A position could also be represented in a form that merely implies a physical 
location, rather than indicating it directly. For example, a position could be represented 
by the name or ID of a node within a graph, as illustrated in FIG. 35. FIG. 35 shows 
several links 203a, 203b, 203c and others not labeled. Link 203a connects from node 
204a to node 204b, link 203b connects from node 204c to node 204b, and link 203c 
connects from node 204d to node 204c. Or, a position could be represented as the ID 
number of a particular cellular phone cell in which the Vehicle is operating. 

If the positions that are reported by the Geolocator do not correspond directly to 
locations that are represented in the MapDatabase, then it may be necessary to reconcile 
the VehicleLocation data against the MapDatabase 1 s location data, in order to determine a 
Vehicle's position relative to locations represented in the MapDatabase, as previously 
discussed. For example, if a VehicleLocation position is represented by arbitrary x,y 
coordinates, but the MapDatabase uses a graph of nodes and links to represent road 
locations, then the reconciliation process will determine a RoadPosition, within the graph, 
that corresponds to the reported VehicleLocation position. On the other hand, if the 
Geolocator represents positions by node names within the MapDatabase 1 s graph, then the 
process of reconciliation is a no-op, because no reconciliation is required. 

It should be understood to one skilled in the art that various representations for the 
Vehicle's position are possible, and the particular representation is not an essential aspect 
of this system. For purposes of this discussion, and without loss of generality, assume 
that the Vehicle's position is represented as a point in an prescribed two-dimensional 
Cartesian coordinate system, unless otherwise indicated. 

SECOND MAJOR EMBODIMENT: 

TVKT I VERING CUSTOM TRA VEL-REL ATED INFORMATION 

In another embodiment, illustrated in FIG. 36, a variation of system 100, 
designated system 1100, provides custom travel-related information to a Vehicle, based 
on the Vehicle's location. In this embodiment, system 1100 comprises: (a) source 1101 
(the "Geolocator") for automatically geolocating a Vehicle; (b) a database 1102 (the 
"MapDatabase") of location-sensitive information; (c) interposed processor 1104 (the 
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"SelectionAlgorithnT) for selecting relevant travel-related information based on the 
reported location of the Vehicle; (d) and a guidance system 1105 (the "Guide") for 
delivering said travel information to the Vehicle. 

In FIG. 36, Geolocator 1101 detennines the location of Vehicle 162. The 
5 SelectionAlgorithm 1104 then uses this location data to select travel-related information 
from MapDatabase 1102 and pass the selected information to the Guide 1105, which 
sends the selected information to the Vehicle 162. 

Geolocator 1101 is used to determine the approximate current location (the 
"VehicleLocation") of the Vehicle by passively geolocating the Vehicle's mobile 
10 transmitter. 

MapDatabase 1102 provides location-sensitive information, i.e., information that 
is relevant to specific geographic areas. (In a preferred embodiment, the MapDatabase 
contains such information in a database. However, in another embodiment the 
MapDatabase simply communicates with an external device or system that would supply 
15 such information, such as from a Traffic Control center database, rather than containing 
such a database itself.) 

For example, in one embodiment the MapDatabase may contain infoimation about travel 
times for specific road segments, or between specific locations. MapDatabase 1 102 may 
also contain information about traffic incidents pertaining to specific geographic areas. 

20 The MapDatabase may also contain information about the locations and operating hours 
of various services, such as service stations, hotels, points of interest, businesses or 
residences. Or, MapDatabase 1102 may additionally contain information about the kinds 
of vehicles permitted on certain roads. Such information might be particularly valuable to 
truckers, for example. Thus, in various embodiments, MapDatabase 1102 is presumed to 

25 contain any kind of location-sensitive information, i.e. , information that is relevant to 
specific geographic areas. 

In one embodiment, MapDatabase 1102 contains location-sensitive information 
pertaining to areas that do not necessarily correspond to individual roads, such as areas 
corresponding to cell sites of a cellular phone system, or grid areas on a map. For 
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example, MapDatabase 1102 simply maintains a table that associates current location- 
sensitive information with cell sites, as illustrated in Table 14. 

To select travel-related information that is relevant to a Vehicle's current or 
anticipated location, the SelectionAlgorithm simply uses the cell site of the Vehicle's 
5 location to look up the associated location-sensitive information in the table. For 
example, if the Vehicle is located in CellSitelD #9002, then the associated location- 
sensitive information in Table 14 includes "Construction at Market St. and 46 St." and^ 
"Mobil station at Market St. and 47th Street, open 6am-10pm daily". 

The SelectionAlgorithm selects travel-related information that is relevant to the 
10 Vehicle's current or anticipated location. The SelectionAlgorithm operates as shown in 
flow chart 3600 of FIG. 37. The SelectionAlgorithm begins at Start block 3601, receives 
a VehicleLocation from the Geolocator as invoked by processing block 3602, applies a 
prescribed algorithm via block 3603 to select relevant travel-related information 
("Travellnfo") from the MapDatabase, based on the VehicleLocation, and uses the Guide 
15 to output the Travellnfo to the Vehicle, as depicted by processing block 3604. The 
processing flow terminates at Done block 3605. 

At a minimum, the SelectionAlgorithm computes or selects Travellnfo that is 
deemed relevant to the Vehicle, given a VehicleLocation. Such Travellnfo may comprise 
a route plan to a predetermined destination, information about a change to a previously 
20 selected route plan, an estimated time of arrival at a predetermined destination, 

information about a change from a previously estimated time of arrival, guidance toward 
a destination, a reminder of an upcoming exit or road change, traffic conditions in the 
Vehicle's current or anticipated vicinity, the location of gas stations or other services, or 
any other travel-related information that is relevant to a particular geographic area. 

25 The SelectionAlgorithm output is used by the Guide to deliver the selected 

Travellnfo to the Vehicle. This Travellnfo may be in any format that is convenient for 
both the SelectionAlgorithm and the Guide. In one embodiment, the Travellnfo may be 
represented as text, for example "30 MINUTE DELAYS AT WALT WHITMAN 
BRIDGE ON EASTBOUND 76". In another embodiment, the Travellnfo may represent 

30 audio data, for example, an audio recording of "30 minute delays at Walt Whitman 
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Bridge on Eastbound 76" . 

The Guide converts the selected Travellnfo to a format that is acceptable to the 
Vehicle's mobile receiver, if necessary, and sends the result to the Vehicle. In one 
preferred embodiment, the Guide converts the Travellnfo from text to speech and delivers 
the result to the Vehicle via a cellular phone connection, as a synthesized voice. For 
example, the Guide tells the user of the Vehicle, via cellular phone, "30 minute delays at 
Walt Whitman Bridge on Eastbound 76", or "Go East on Chestnut Street for 1.6 miles", 
or "Travel 3 more blocks . . . 2 more blocks ... one more block . . . Next right on 
Park Avenue. " In another embodiment the Travellnfo is sent as a text message to display 
on a pager carried by the Vehicle. 

In one preferred embodiment, the Vehicle's mobile transmitter, by which the 
Vehicle is geolocated, and the Vehicle's receiver, by which the Vehicle receives selected 
Travellnfo, are embodied in a cellular phone, thus requiring no other special equipment in 
the Vehicle. In another embodiment, the Vehicle's receiver may be embodied in a pager. 
Many other embodiments are also possible. 

The above description has shown how system 1100 can provide custom travel- 
related information to a Vehicle. For concreteness, and without loss of generality, system 
1100 has been described as providing travel-related information to a single Vehicle. 
However, it should be obvious to one skilled in the art that in a preferred embodiment 
system 1100 is generally arranged to service multiple Vehicles or users by separately 
keeping track of the processing state pertaining to each Vehicle or user. Additional 
variations to system 1100 are now discussed. 

I. Specifying TTser Options 

Often it is desirable to allow a user to further customize the travel-related 
information that system 1100 selects and delivers, rather than just customizing the 
information based on Vehicle location. 

To do so, system 1100 allows inputs, options or preferences to be specified, either 
by the user or by another device or person. For example, the user selects from a menu of 
various options using the touch tone cellular phone buttons, or the user specifies 
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preferences orally, over the phone, to a speech recognition system or to an operator who 
inputs the information to system 1100. In another embodiment, the user's options are also 
stored as a profile of common preferences or defaults, for use on other occasions. One 
such input might be a desired destination or set of destinations. Another example might 
be a category of roads to use or avoid, such as super-highways or roads disallowing 
trucks. Another example might be to select a specific route from among various options. 
Yet another example might be a desired category of location-sensitive information, such 
as "Service Stations", "Hotels" or "Traffic Incidents". Such categories could be indicated 
in the MapDatabase 1102, as illustrated in Table 15, for example. 

Each row in Table 15 represents a record of location-sensitive information. The 
"Category" column indicates what kind of information the record describes. The 
"CellSitelD" column indicates the area to which the information in this row pertains. The 
"Position" column indicates a more precise location of the incident or service. (Such 
Position information is used, for example, to guide a Vehicle to the location of a desired 
service, as discussed below.) Finally, the "Location-sensitive Information" column holds 
the body of the location-sensitive information. 

n. Providine Route Plan Information 

One of the most preferred embodiments of system 1 100 provides custom route 
plan information and other travel time related information to Vehicles. The following 
describes how such information can be provided. 

In this embodiment, MapDatabase 1102 contains travel times and locations for 
specific road segments. MapDatabase 1102 contains static location-sensitive information, 
but in a preferred embodiment, it also includes dynamic location-sensitive information 
reflecting current travel conditions. 

Using MapDatabase 1102, SelectionAlgorithm 1104 applies a prescribed algorithm 
to select a route to one or more destinations. For example, if MapDatabase 1102 uses a 
directed graph to represent road segments, as previously discussed, then an algorithm 
could select the fastest route to the user's destination. Other criteria could also be used to 
select a preferred route. Using the same or other techniques, SelectionAlgorithm 1104 
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could also estimate the Vehicle's arrival time at the destination by summing the travel 
times incurred along the route to the destination. If each link also indicates the length of 
the road segment that it represents, then the travel distance to the destination can be 
computed by summing the lengths incurred along the route to the destination. (Of course, 
the length need not be explicitly represented on each link ; The length could simply be 
implied by the end point locations of the road segment, or by any other suitable means.) 

There are many algorithms, well known in the field, for finding the fastest route, 
in a graph, from a source location to a destination. One example is shown in Appendix 
A. This algorithm is based on Dijkstra's Algorithm, a well-known shortest path 
algorithm, and works forward through the graph, from source to destination. Given a 
source node, a destination node and a departure time from the source node, this algorithm 
finds the fastest route to the destination and computes the estimated arrival time at the 
destination. 

Once SelectionAlgorithm 1 104 has selected a route plan to the destination, Guide 
1105 delivers this information, or a subset thereof, to Vehicle 162. This completes the 
description of how system 1100 provides custom route plan information to a Vehicle. 
Further additional variations of system 1100 are now described. 
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m. Estimating a Necessar y Departure Time 

A shortest-path algorithm to estimate the arrival time of a Vehicle at a 
destination, given the departure time at the source, was previously discussed. What if the 
Vehicle needs to arrive at the destination at a particular time, and wants to know when to 
5 depart from the source? It is easy to modify a typical shortest-path algorithm to compute 
the necessary departure time from a source location, given the desired arrival time at a 
destination. Basically, the algorithm just works in the opposite direction, working 
through the graph from the destination back to the source location. This is illustrated in 
the algorithm of Appendix B, which is a straightforward modification of the algorithm of 
10 Appendix A. 

V. Updating the MapDatabase 

In one preferred embodiment, SelectionAlgorithm 1104 automatically updates the 
data in MapDatabase 1102, as previously described for ProcessingAlgorithm 103 (shown 
in FIG. 6), using data from the Geolocator. MapDatabase 1102 may also be updated from 
15 other external sources also, either manually or automatically. For example, 

ProcessingAlgorithm 103 is arranged to merge travel time or traffic data that is obtained 

from other sources. 

V. Predicting a Vehicle Location 

In another embodiment, SelectionAlgorithm 1104 uses the recent travel path of 
20 Vehicle 162 to more accurately estimate the current road position of Vehicle 162, as 

previously discussed, or to estimate the direction or anticipated future position of Vehicle 
162, as illustrated in FIG. 38. FIG. 38 shows road links 164a-c connecting nodes 163a-d. 
A Vehicle's recent travel path 165 connects RoadPositions that are coincident with nodes 
163a-c. The Vehicle was last geolocated at node 163c, but based on the recent travel path 
25 165, the Vehicle's travel is anticipated to continue along travel path 166 and its next 
RoadPosition is anticipated to be at node 163d. 

Or, SelectionAlgorithm 1104 uses a previously stored route in order to anticipate 
the future position of Vehicle 162. For example, such a stored route might have been 
previously selected by a guidance application. Or, such a stored route might be one of 
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several commonly used routes, known in the geographic area. Or, system 1100 stores a 
profile history of the Vehicle's usual route to work or home, as discussed previously. 
This is illustrated in FIG. 39. 

FIG. 39 shows road links 167a-c connecting nodes 168a-d. A Vehicle was most 
5 recently geolocated at node 168c. Based on stored route 169, the Vehicle's next 
RoadPosition is anticipated to be at node 168d. 

VI. Real-time Route Guidance 

In another preferred embodiment, system 1100 provides real-time travel-related 
information, such as route guidance, to the user of a Vehicle, as the Vehicle travels. For 

o example, in a guidance application, system 1100 tracks the Vehicle's movement and 
notifies the Vehicle of the next action to take at each approaching intersection, exit or 
other decision point. Or, system 1 100 performs route selection repeatedly as the Vehicle 
travels, and notifies the user of any recommended changes to a previously selected route, 
based on the Vehicle's current position. If system 1100 makes use of dynamic location- 

5 sensitive information, then the Vehicle's recommended route can then be automatically 
changed in response to changes in travel conditions. System 1 100 also notifies the 
Vehicle if the Vehicle appears to be going the wrong direction. This can be done by 
tracking the Vehicle's progress to see if it deviates from the selected route. One practical 
way to do this is have the SelectionAlgorithm watch for an increase, beyond a prescribed 

10 threshold, in the estimated travel distance from the specified destination. 

VII. Dispatching Vehicles 

In another embodiment, system 1100 assists in dispatching any of several Vehicles 
to a specific location, in response to a request. This is used, for example, in taxi 
dispatching, to select the taxi that can arrive at the customer's location the soonest. For 
15 example, a customer might use a cellular or conventional phone to call an automatic taxi 
dispatcher. The location of each available taxi could be tracked by geolocating each taxi's 
cellular phone, or by other means. The customer's location might also be determined by 
geolocating the customer's cellular phone, or, in the case of a conventional telephone, by 
looking up the location in a database, such as is done currently for emergency "911" 
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calls. System 1100 estimates the travel time required for each available taxi to reach the 
customer's location, and dispatches the taxi with the earliest estimated arrival time. 
System 1100 also automatically patches the customer through to the taxi driver, 
establishing a voice connection from the customer to the driver, by telephone or radio, so 
that the customer and driver could discuss any necessary details of the pickup. 
Alternatively, such a dispatching system automatically records special instructions from 
the customer, such as "I have four large suitcases" or "I am at the back of the building at 
1500 Locust Street", and sends them to the taxi driver, via radio or cellular phone. 

In another embodiment, such a dispatching system is also arranged to estimate the 
next available taxi even among occupied taxis, by estimating the time when each occupied 
taxi will become available, and then proceeding as previously described. This can be 
done by estimating the arrival time of each occupied taxi at its destination, and adding an 
estimated passenger unloading time. Of course, these techniques can be applied to many 
other dispatching applications as well. 

In another embodiment, system 1100 is further arranged to assist in dispatching 
emergency vehicles, either automatically or semi-automatically. By tracking the locations 
of available emergency vehicles, and by manually or automatically determining the 
location of the emergency, such a system automatically estimates the potential arrival time 
of each available emergency vehicle, and selects or recommends the one that could arrive 
at the scene the soonest. Furthermore, such a system automatically guides the emergency 
Vehicle to the scene, as previously described. 
Vm. Route Selection for Emergency and Other S pecial Vehicles 

In another embodiment, system 1100 is arranged to use a different route selection 
method or maintain different travel time data for use by emergency vehicles, such as for 
police, fire or emergency medical services, because those vehicles may have different 
travel time characteristics from other vehicles. For example, emergency vehicles may 
travel faster and go through stop lights and stop signs significantly faster than other cars. 
A similar approach could be taken for trucks or other major vehicle categories. 

To automatically determine the kind of travel time data applicable to a specific 
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kind of Vehicle, a database is maintained which associates each cellular phone number (or 
other identifying code) and a Vehicle type ("VehicleType"), as illustrated in Table 16, 
thus allowing the VehicleType to be determined automatically when this system is used to 
provide a service. Or such a database might associate each cellular phone number (or 
5 other identifying code) with a TravelTime multiplier ("TravelTimeMultiplier") that 
indicates how long this Vehicle normally takes to travel, relative to a nominal Vehicle 
TravelTime, as illustrated in Table 17. A link travel time can be multiplied by the 
TravelTimeMultiplier for the Vehicle to estimate the link traversal time for the Vehicle. 

IX. Vehicle Notification 

10 Another function that system 1100 performs is the notification to Vehicles of 

relevant information, such as a traffic incident. Or system 1 100 notifies a Vehicle before 
the Vehicle passes an important decision point, such as an exit. 

In one preferred embodiment, system 1100 monitors a Vehicle's location, and 
automatically notifies the Vehicle of Travellnfo deemed relevant to the Vehicle, either at 

15 the Vehicle user's implicit or explicit behest, or entirely initiated by system 1100. For 
example, system 1100 may provide the user with exit reminders, so as to notify the user 
when the next exit that the user should take, along a previously selected route, is 
approaching. Or system 1100 may notify the Vehicle of upcoming traffic incidents, or 
changes to a selected route plan. Such notification is accomplished by calling the 

20 Vehicle's cellular phone, transmitting an audible tone or message on a previously 
established cellular phone call, or by sending a message to the Vehicle's pager, for 
example. 

In another embodiment, the SelectionAlgorithm is arranged to predict the 
Vehicle's likely route, in the absence of an explicitly specified destination, and to notify 

25 the Vehicle of unusual travel conditions relative to the Vehicle's predicted route. For 
example, the SelectionAlgorithm estimates the Vehicle's direction of travel, using the 
TravelPath computed from the Vehicle's TrackingSequence, and, as one simple heuristic, 
assumes that the Vehicle will continue in the same direction along the same road. For 
example, system 1100 could inform a Vehicle traveling North on route 295 approaching 

30 exit 36: "Accident on 295 Northbound at exit 40. Please detour at exit 36." Other more 
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sophisticated techniques of predicting the Vehicle's likely route are also possible. For 
example, the SelectionAlgorithm uses a previously stored user profile of common routes, 
such as the user's usual route to work or home, to predict the Vehicle's likely route 
without requiring explicit destination information. 

In another embodiment, system 1100 notifies the Vehicle of the existence of a 
potentially relevant traffic message, and solicits the Vehicle user's agreement to pay a fee 
in exchange for receiving the traffic message. For example, by cellular phone, system 
1100 notifies a Vehicle traveling North on route 295 approaching exit 36: "For $2.99 you 
can receive this traffic notification message. Press '1' now if you wish to receive this 
traffic notification message" . If the user indicates acceptance by pressing " 1 " on his/her 
cellular phone, then system 1100 sends the message "Accident on 295 Northbound at exit 
40. Please detour at exit 36". In another embodiment, system 1100 also solicits or 
guesses the Vehicle's destination, and re-computes a new route to avoid the obstruction. 

THIRD MAJOR EMBODIMENT: TH IRD PARTY 
TRAVPT .-RET ATED INFORMATION 
The preceding two major sections have presented how location- sensitive 
information can be generated, and how custom selected travel-related information can be 
delivered to a Vehicle. This section describes how a third party user can obtain travel- 
related information from such systems as system 100 or system 1100. Such a user might 
20 be a dispatcher selecting a route for delivery vehicles, a user at home checking on travel 
conditions to work, a pedestrian needing a taxi, or a person in distress needing emergency 
assistance, for example. An embodiment of this variation, designated system 2100, is 
now described. System 2100 is illustrated in FIG. 40. 

System 2100 allows a third party user at a remote location to obtain travel-related 
25 information. With reference to FIG. 40, this embodiment comprises: (a) a means 2102 
(the "MapDatabase") for accessing location-sensitive information, wherein said 
information is associated with one or more specific geographic areas, and furthermore 
said information includes data that was derived from passively geolocating and tracking 
one or more mobile transmitters; (b) a selection processor 2104 (the 
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"SelectionAlgorithm") for selecting travel-related information, based on one or more 
locations of interest; and (c) guide system 2105 (the "Guide") for sending selected travel- 
related information to remote user 2106. 

MapDatabase 2102 stores and provides location- sensitive information. In a 
5 preferred embodiment, such location-sensitive information is updated dynamically. In 
particular, in one preferred embodiment, such location-sensitive information is updated, 
in part, using geolocation data obtained by passively geolocating mobile transmitters, as 
previously discussed. 

SelectionAlgorithm 2104 selects travel-related information relevant to one or more 
10 locations and uses Guide 2105 to deliver the selected information to remote user 2106. 
Guide 2105 may use the cellular phone system, the conventional phone system, pager 
communication, radio communication, electronic mail, the Internet, or any other means 
for delivering the selected travel-related information to remote user 2106, who may or 
may not be carried in a vehicle. 

15 In one embodiment, system 2100 allows remote user 2106 to specify inputs, 

options or preferences, as previously discussed. For example, the user might specify a 
location of interest. Or, the user might specify a source location and a destination, and 
system 2100 selects a route from the source location to the destination and sends the 
information about the selected route, such as directions and travel time, for the fastest 

20 route from the source location to the destination location, to the user. System 2100 is 
also used in dispatching delivery vehicles, for example. Many other kinds of travel- 
related information could be supplied also, as previously discussed. 

In another embodiment, system 2100 estimates the departure time, from a source 
location, necessary to arrive at a destination at a particular time, and notifies remote user 

25 2106. For example, system 2100 initiates a "wake up" phone call when it is nearing time 
to leave. Or system 2100 sends an electronic mail message, or a pager message. Or 
system 2100 notifies user 2106 only if the estimated departure time differs sufficiently 
from a previously assumed or usual departure time. Or system 2100 notifies user 2106 if 
the newly selected route differs from a previously selected route, such as the user's usual 

30 route to work. Or system 2100 notifies user 2106 of any traffic incidents on the user's 
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usual route to work, for example. 

Although various embodiments which incorporate the teachings of the present 
invention have been shown and described in detail herein, those skilled in the art can 
readily devise many other varied embodiments that still incorporate these teachings. 


Table 1; Unsorted VehicleLocation records 


VehiclelD 

Position 

TimeStamp 

12023861234 

38.426,349.592 

78558.9 

13017729988 

38.292,349.362 

78559.9 

13017729988 

38.295,349.348 

78562.9 

13017729988 

38.296,349.346 

78564.2 

13017729988 

38.300,349.332 

78567.9 

12023861234 

38.497,349.543 

78568.5 

12023861234 

38.481,349.516 

78570.4 

13017729988 

jo. Jlo,J4y. 3Lj 

/ OJ l\J. 1 

13017729988 

38.312,349.315 

78572.8 

13017729988 

38.332,349.281 

78574.7 

12023861234 

38.554,349.501 

78574.9 

13017729988 

38.331,349.277 

78575.9 

12023861234 

38.534,349.462 

78576.4 

12023861234 

38.544,349.462 

78578.0 

13017729988 

38.347,349.249 

78579.7 

12023861234 

38.573,349.478 

78579.8 

12023861234 

38.571,349.454 

78581.2 

13017729988 

38.359,349.225 

78581.5 

12023861234 

38.580,349.459 

78582.8 

13017729988 

38.373,349.201 

78584.7 

13017729988 

38.375,349.190 

78586.3 

12023861234 

38.578,349.421 

78586.8 

12023861234 

38.594,349.413 

78588.6 
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Table 2: VehicleLocation records sorted by VehicleDD 


V cnicic.LL' 

X (J LIU? 11 

TimeStamD 

A XX 1 IV L.C4.X ilU 

12023861234 

oo ylOA 1AQ ^QO 

7£^R Q 

/ OJJO,7 

12023861234 

JO. HO lyJHy.D iO 


12023861234 

1 9 407 ^AQ 

/ OjOO.J 

12023 ©61234 

->o *2/IO 

3o\ j34, j^V.hOZ 

19. ^7A /l 

12023861234 

'iQ ^/l/l 1AQ A£Si 

/ oj fo.U 

12023861234 

-JQ CC/1 1/IQ cni 

/oj /*f.y 

12023861234 

1Q ^71 *2/lQ 

78^S1 0 
/OJOl.Z 

1 ^AOO 1 OO A 

12023861234 

to C'TI Q/IO A*7C 

/oj /i?.o 

12023861234 

IO C7C *7/IG /t'Jl 

/ojoO.o 

12023861234 

cort i/io /tea 
3o. joU,34y.4j9 

7QCOO Q 

/ojoZ.o 

12023861234 

^O/t 1/1Q /111 
35.->y4,34y.*H3 

70COO £L 

/ojoo.O 

13017729988 

1Q OOO "l^l 

3o.zyz,J4y.3oz 

/ OJJ7.7 

1 ^01 777QQRR 

38 295 349 348 

78562.9 

13017729988 

38.296,349.346 

78564.2 

13017729988 

38.300,349.332 

78567.9 

13017729988 

38.312,349.315 

78572.8 

13017729988 

38.318,349.315 

78570.7 

13017729988 

38.331,349.277 

78575.9 

13017729988 

38.332,349.281 

78574.7 

13017729988 

38.347,349.249 

78579.7 

13017729988 

38.359,349.225 

78581.5 

13017729988 

38.373,349.201 

78584.7 

13017729988 

38.375,349.190 

78586.3 


Table 3: TrackingSequence of VehicleLocation records for a 

Vehicle 


Record 

Label in 

Position 

TimeStamp 

Number 

Figure 8 



1. 

114a 

38.426,349.592 

78558.9 

2. 

114b 

38.497,349.543 

78568.5 

3. 

114c 

38.481,349.516 

78570.4 

4. 

114d 

38.554,349.501 

78574.9 

5. 

114e 

38.534,349.462 

78576.4 

6. 

114f 

38.544,349.462 

78578.0 

7. 

114g 

38.573,349.478 

78579.8 

8. 

114h 

38.571,349.454 

78581.2 

9. 

114i 

38.580,349.459 

78582.8 

10. 

114j 

38.578,349.421 

78586.8 

11. 

114k 

38.594,349.413 

78588.6 
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Table 4: TrackingSequence after smoothing 


J — 

Record 

T anAl in 
L^aVCl 111 


TimeStamo 

iNuiiiDer 




1. 

1 15a 

yfOA 'J/IQ ^Q? 

78558 9 

9 

118b 

38.468,349.550 

78568.5 

3. 

118c 

38.511,349.520 

78570.4 

4. 

118d 

38.523,349.493 

78574.9 

5. 

118e 

38.544,349.475 

78576.4 

6. 

118f 

38.550,349.467 

78578.0 

7. 

118g 

38.563,349.465 

78579.8 

8. 

118h 

38.575,349.464 

78581.2 

9. 

118i 

38.576,349.445 

78582.8 

10. 

118j 

38.584,349.431 

78586.8 

11. 

118k 

38.594,349.413 

78588.6 


Table 5: TrackingSequence after smoothing, indicating 
records to be deleted to consolidate records 


Record 

Label in 

Position 

TimeStamp 

Number 

Figure 14 



1. 

118a 

38.426,349.592 

78558.9 

:i2? : F:t.';: ; \vi 


; £j8y6£349B5pr': 


3. 

118c 

38.511,349.520 

78570.4 

4. 

118d 

38.523,349.493 

78574.9 



^8^44;339v475«;y 


6. 

118f 

38.550,349.467 

78578.0 





8. 

118h 

38.575,349.464 

78581.2 

9. 

U8i 

38.576,349.445 

78582.8 


.•■Tl»}ir.:;.;;j;.. 



ii. 

118k 

38.594,349.413 

78588.6 

Table 6: TrackingSequence after smoothing and 



consolidating 


Record 

Label in 

Position 

TimeStamp 

Number 

Figure 15 



1. 

118a 

38.426,349.592 

78558.9 

3. 

118c 

38.511,349.520 

78570.4 

4. 

118d 

38.523,349.493 

78574.9 

6. 

118f 

38.550,349.467 

78578.0 

8. 

118h 

38.575,349.464 

78581.2 

9. 

118i 

38.576,349.445 

78582.8 

11. 

118k 

38.594,349.413 

78588.6 
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Table 7: A TrackingSequence containing a cluster of points in close 


proximity 


Record 
Number 

Label in 
Figure 16 and 
Figure 17 

Position 

TimeStamp 

1. 

119a 

38.362,349.033 

80983.59 








180987^ 

>* 

4. 

119b 

38.369,348.967 

80993.28 

:!"^, : |:V-- : --" - -- ■*•-■"" 




6. 

119c 

38.378,348.925 

80996.45 
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::8t04©i& : v :y 




^8:l042:44ai ; ^^> ; vf 

28. 

119d 

38.385,348.902 

81046.11 




:8l048;Mty 





31. 

119e 

38.392,348.870 

81054.06 



:3Si ; 39^348^5?f:t:: : t':.:; 





^5:187^^.- : ?e--:: : -.; 

34. 

119f 

38.397,348.844 

81060.49 
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Table 8: A TrackingSequence with clusters of points removed 


Record 
Number 

Label in 
Figure 16 and 
Figure 17 

Position 

TimeStamp 

1. 

119a 

38.362,349.033 

80983.59 

4. 

119b 

38.369,348.967 

80993.28 

6. 

119c 

38.378,348.925 

80996.45 

28. 

119d 

38.385,348.902 

81046.11 

31. 

119e 

38.392,348.870 

81054.06 

34. 

119f 

38.397,348.844 

81060.49 


Table 9: Nodes of a graph corresponding to VehicleLocation 

records of Table 8 


Record 

Label in 

Position 

Node 

Number in 

Figure 16 and 


Number in 

Table 8 

Figure 17 


Figure 18 

1. 

119a 

38.362,349.033 

121a 

4. 

119b 

38.369,348.967 

121b 

6. 

119c 

38.378,348.925 

121c 

28. 

119d 

38.385,348.902 

121d 

31. 

119e 

38.392,348.870 

121e 

34. 

119f 

38.397,348.844 

121f 


Table 10: Links of a graph corresponding to 


VehicleLocation records of Table 8 


Link Label 

FromNode 

ToNode 

TravelTime 

in Figure 18 

(Label in 

(Label in 

(seconds) 


Figure 18) 

Figure 18) 


122a 

121a 

121b 

9.7 

122b 

121b 

121c 

3.2 

122c 

121c 

121d 

49.7 

122d 

121d 

121e 

7.9 

122e 

121e 

121f 

6.4 
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Table 11: Links of a graph corresponding to VehicleLocation records of Table 8 


Link Label 
in Figure 25 


141a 


FromNode 
(Label in 
Figure 25) 


142a 


ToNode 
(Label in 
Figure 25) 


142b 


Expected 

Link 
TravelTime 
(seconds) 


9.7 


Weight 


12.6% 


Proroated 
Measured " 
TravelTime 
(seconds) 


11.6 


141b 


142b 


142c 


3.2 


4.1% 


3.8 


141c 


142c 


142d 


49.7 


64.6% 


59.6 


141d 


142d 


142e 


7.9 


10.3% 


9.5 


141e 


142e 


142f 


6.4 


8.4% 


Totals 


76.9 


100.0% 


7.7 


92.3 


Table 12: Hypothetical average travel times for a 
specific road link during different times of a typical 
weekday 


Time of Day 

Average Travel Time (seconds) 

6:00am 

20 

6:30am 

21 

7:00am 

23 

7:30am 

25 

8:00am 

28 

8:30am 

29 

9:00am 

29 

9:30am 

27 

10:00am 

24 


5 

Table 13: Hypothetical rainy weather travel time adjustments for a specific road 

link 


Time of Day 

Average Travel Time in Good 
Weather (seconds) 

Rainy Weather Travel Time 
Adjustment (seconds) 

6:00 

20 

+6 

6:30 

21 

+6 

7:00 

23 

+8 

7:30 

25 

+9 

8:00 

28 

+12 

8:30 

29 

+14 

9:00 

29 

+14 

9:30 

27 

+10 

10:00 

24 

+8 
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Table 14: Table of cell sites and information 


Cell SitelD 

Location-sensitive Information 

9001 

Sunoco station at Hartford Rd and US 38, open 24hrs daily 

9002 

Construction at Market St and 46 St. 

9002 

Mobil station at Market St and 47th Street, open 6am-10pm daily 

9003 

30 minute delays on Eastbound 76 at Walt Whitman Bridge 

9004 

Accident on 295 Southbound at exit 36 


Table 15: Table of cell sites and information, with categories and positions 


Category 

Cell SitelD 

Position 

Location-sensitive Information 

services 

9001 

38.362,349.033 

Sunoco station at Hartford Rd and US 38, 
open 24hrs daily 

delays 

9002 

38.369.348.967 

Construction at Market St and 46 St. 

services 

9002 

38.378,348.925 

Mobil station at Market St and 47th Street, 
open 6am- 10pm daily 

delays 

9003 

38.385,348.902 

30 minute delays on Eastbound 76 at Walt 
Whitman Bridge 

delays 

9004 

38.392,348.870 

Accident on 295 Southbound at exit 36 


Table 16: VehiclelDs and VehicleType 


VehiclelD 

VehicleType 

13017729988 

Car 

12023861234 

Car 

12024724556 

Truck 

12026861221 

Emergency 

13017679998 

Truck 

13018267649 

Car 

12026861249 

Emergency 

12024883747 

Car 


Table 17: VehiclelDs and TravelTimeMultipliers 


VehiclelD 

TravelTimeMultiplier 

13017729988 

0.9 

12023861234 

1.0 

12024724556 

1.2 

12026861221 

0.8 

13017679998 

1.3 

13018267649 

1.0 

12026861249 

0.7 

12024883747 

1.1 


SIBSTTIUTE SHEET (RULE 26) 
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APPENDIX A: Fastest Pat h Algorithm 

This algorithm finds the fastest path, in a directed graph, from a source node to a 
destination node. It is a version of Dijkstra's algorithm. 

5 The directed graph is assumed to consist of a set of nodes and a set of directed links, in 
which each link represents a road segment, and each node represents a physical location. 

Each link is assumed to have the following attributes: 

FromNode The node from which this link connects. 

ToNode The node to which this link connects. 

10 Hie algorithm may also give each node the following attributes: 

arrivalLink The link, along the currently-fastest path, by which this node 

was reached. 

arrivalTime The arrival time at this node, traversing along the currently- 

fastest path. 

15 Each node may also be labeled as "Reached" or "Unreached", at various points as the 
algorithm progresses. 

This algorithm also assumes that there is a function, 

ExpectedLinkTravelTime(l,t) 

that yields the expected incremental travel time required to traverse link 1 starting at time 
20 t. If the travel time for link 1 is constant for all times, then this function simply represents 
an association between a link and a travel time. This function is intended to account for 
different travel times, for the same road segment, at different times of the day or different 
days. 

This algorithm has the following inputs: 

25 sourceNode The source node from which the fastest path to the destination 

node is desired. 

destinationNode The destination node. 

departureTime The anticipated departure time from sourceNode. 

This algorithm produces the following outputs: 

30 pathToDestination A sequence of links representing the fastest path from the 

sourceNode to the destinationNode. 

arrivalTime of destinationNode The estimated time of arrival at the 

destinationNode . 

This algorithm uses the following variables: 

35 Variable Explanation 


sourceNode 


The starting node. 
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destinationNode The ending node. 

departureTime The departure time from the starting node. 

frontierNodes A set of nodes representing the frontier of our breadth-first 

search of the graph. These are nodes that have yet to be 
5 "expanded". 

nodeToExpand The next node to be expanded, i.e. , we will next search from 

this node. 

candidateLink The next link to be traversed in our search, 
eltt Expected link travel time for candidateLink. 

10 cat Candidate arrival time, i.e. , arrival time at the ToNode of 

candidateLink. 

pathToDestination The list of links comprising the fastest path leading from the 

sourceNode to the destinationNode. 
currentNode Current node in constructing the path from thesourceNode to 

IS the destinationNode. 

The algorithm has the following steps. 

1 . Get input: 

Input sourceNode. 
Input destinationNode. 
20 Input departureTime. 

2. Initialize for fastest path search: 

Mark all nodes "Unreached". 

SET arrivalTime of sourceNode : = departureTime. 

SET frontierNodes : = { sourceNode }. 

25 3. SEARCH_LOOP: 

Check for an unreachable destination: 
IF frontierNodes is empty 
THEN BEGIN 

Output "Destination is unreachable from source" . 
30 STOP 

END 

4. Select a node nodeToExpand from frontierNodes such that nodeToExpand has the 
minimum arrivalTime of all nodes in frontierNodes. 

5. Delete nodeToExpand from frontierNodes. 
35 6. See if we have reached the destination: 

IF nodeToExpand = = destinationNode 

THEN GOTO REACHED JDESHNATTON (step 9). 

7. (Comment: This step is known as "expanding" node nodeToExpand.) For each link 
candidateLink whose FromNode is nodeToExpand, do the following: 

40 BEGIN 

COMMENT: eltt means "expected link travel time". 

SET eltt : = ExpectedLinkTravelTime(candidateLink, 
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arrivalTime of nodeToExpand). 
COMMENT: cat means "candidate arrival time". 
SET cat : = eltt + arrivalTime of nodeToExpand. 
IF ToNode of candidateLink is "Unreached" 
5 OR cat < arrivalTime of ToNode of candidateLink 

THEN BEGIN 

SET arrivalTime of ToNode of candidateLink: = cat. 

SET arrivalLink of ToNode of candidateLink : = 

candidateLink. 

10 EF ToNode of candidateLink is "Unreached" 

THEN BEGIN 

Mark ToNode of candidateLink as "Reached". Add 
ToNode of candidateLink to firontierNodes. 
END 

15 END 
END 

8. GOTO SEARCH LOOP (step 3). 

9. REACHED_DESHN ATION : 

Initialize for constructing the path from sourceNode to destinationNode: 
20 SET pathToDestination : = {}. 

SET currentNode : = destinationNode. 

10. Construct the path from sourceNode to destinationNode: 

WHILE (currentNode ! = sourceNode) 
BEGIN 

25 Insert arrivalLink of currentNode as the first link in 

pathToDestination. 

SET currentNode : = FromNode of arrivalLink of 

currentNode. 
END 

30 11. Output the results: 

Output pathToDestination. 

Output arrivalTime of destinationNode. 

12. STOP 
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APPENDIX B: Fastest Path Algorith m (Backwards Version) 

This is a modified version of the previous Fastest Path Algorithm. This algorithm also 
finds the fastest path, in a directed graph, from a source node to a destination node. 
However, given a destination and a desired arrival time at the destination, this algorithm 
5 will also compute the latest possible departure time, from the source, that is required to 
the destination at the desired arrival time. To do so, this algorithm works backwards 
through the graph, from destination to source. 

The directed graph is assumed to consist of a set of nodes and a set of directed links, in 
which each link represents a road segment, and each node represents a physical location. 

10 Each link is assumed to have the following attributes: 

FromNode The node from which this link connects. 

ToNode The node to which this link connects. 

The algorithm may also give each node the following attributes: 

departurelink The link, along the currently-fastest path, by which this node 

!5 was reached. 

departureTime The departure time at this node, traversing along the 
currently-fastest path. 

Each node may also be labeled as "Reached" or "Unreached", at various points as the 
algorithm progresses. 
20 This algorithm also assumes that there is a function, 
ExpectedLinkTravelTime(l,t) 

that yields the expected incremental travel time required to traverse link 1 ending at time t. 
If the travel time for link 1 is constant for all times, then this function simply represents 
an association between a link and a travel time. This function is intended to account for 
25 different travel times, for the same road segment, at different times of the day or different 
days. 

This algorithm has the following inputs: 

sourceNode The source node from which the fastest path to the destination 

node is desired. 

30 destinationNode The destination node. 

arrivalTime The desired arrival time at destinationNode. 

This algorithm produces the following outputs: 

pathToDestination A sequence of links representing the fastest path from the 

sourceNode to the destinationNode. 

35 departureTime of sourceNode The time required to depart from sourceNode 

in order to arrive at destinationNode at 
arrivalTime. 

This algorithm uses the following variables: 
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Variable Explanation 

sourceNode The starting node. 

destinationNode The ending node. 
5 arrivalTime The desired arrival time at destinationNode. 

frontierNodes A set of nodes representing the frontier of our 

breadth-first search of the graph. These are nodes that have 

yet to be "expanded". 
nodeToExpand The next node to be expanded, i.e. , we will next search from 
10 this node. 

candidateLink The next link to be traversed in our search. 

eltt Expected link travel time for candidateLink. 

cdt Candidate departure time, i.e., the departure time from the 

FromNode of candidateLink. 
15 pathToDestination The list of links comprising the fastest path leading from the 

sourceNode to the destinationNode. 
currentNode The current node in constructing the path from the 

sourceNode to the destinationNode. 

The algorithm has the following steps. 

20 1 . Get input: 

Input sourceNode. 
Input destinationNode. 
Input arrivalTime. 

2. Initialize for fastest path search: 
25 Mark all nodes "Unreached". 

SET departureTime of destinationNode : = arrivalTime. 
SET frontierNodes : = { destinationNode }. 

3. SEARCHJLOOP: 

Check for an unreachable source: 
30 IF frontierNodes is empty 

THEN BEGIN 

Output "Source is unreachable from destination". 

STOP 

END 

35 4. Select a node nodeToExpand from frontierNodes such that nodeToExpand has the 
maximum departureTime of all nodes in frontierNodes. 

5. Delete nodeToExpand from frontierNodes. 

6. See if we have reached the source: 

IF nodeToExpand = = sourceNode 
40 THEN GOTO REACHED JSOURCE (step 9). 

7. (Comment: This step is known as "expanding" node nodeToExpand.) 

For each link candidateLink whose ToNode is nodeToExpand, do the following: 
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BEGIN 

COMMENT: eltt means "expected link travel time". 
SET eltt : = ExpectedLinkTravelTime(candidateLink, 

departureTime of nodeToExpand). 
5 COMMENT: cdt means "candidate departure time". 

SET cdt : = departureTime of nodeToExpand - eltt. 
IF FromNode of candidateLink is "Unreached" 
OR cdt > departureTime of FromNode of candidateLink 
THEN BEGIN 
10 SET departureTime of FromNode of candidateLink : = cdt. 

SET departureLink of FromNode of candidateLink : = 

candidateLink. 

IF FromNode of candidateLink is "Unreached" 
THEN BEGIN 
15 Mark FromNode of candidateLink as "Reached". 

Add FromNode of candidateLink to frontierNodes. 

END 

END 

END 

20 8. GOTO SEARCH_LOOP (step 3). 
9. REACHED_SOURCE: 

Initialize for constructing the path from sourceNode to destinationNode: 
SET pathToDestination := {}. 
SET currentNode : = sourceNode. 

25 10. Construct the path from sourceNode to destinationNode: 
WHILE (currentNode ! = destinationNode) 
BEGIN 

Append departureLink of currentNode as the last link in pathToDestination. 
SET currentNode : = ToNode of departureLink of currentNode. 
30 END 

1 1 . Output the results: 

Output pathToDestination. 

Output departureTime of sourceNode. 

12. STOP 
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What is claimed: 

1 1 . A system for generating map database information, the system comprising 

2 (a) a source of vehicle geolocation data, said vehicle geolocation data being 

3 obtained by passively geolocating at least one vehicle carrying a mobile transmitter, 

4 (b) a road location data storage, said road location data being composed of 

5 road segments, and 


6 

7 
8 
9 
10 


2 

1 
2 
3 


(c) means for processing said vehicle geolocation data by applying a 
prescribed algorithm to select, from said vehicle geolocation data, a tracking sequence 
comprising at least two reported positions for a tracked vehicle, said means for processing 
including means for reconciling said tracking sequence against the road location data 
storage to estimate a travel path of the tracked vehicle along one or more road segments 


1 1 corresponding to said tracking sequence. 

l 2. The system of claim 1 wherein said means for processing includes means for 


estimating the location of at least one road segment from said vehicle geolocation data. 

3. The system of claim 1 wherein said vehicle geolocation data includes time 
stamps, and said means for processing includes means for computing an estimated vehicle 
travel time for at least one road segment along said travel path with reference to said time 


4 stamps. 


l 


4. The system of claim 3 further comprising a travel time database for storing 
2 travel time data for specific road segments. 

1 5. The system of claim 4 wherein said travel time database is also used as said 

2 road location data storage. 

6. A system for providing custom travel-related information to a vehicle, the 
vehicle carrying a mobile transmitter and a mobile receiver, said system comprising 

a geolocator for passively geolocating the mobile transmitter, 

4 means for accessing location-sensitive data, 

5 selection means for selecting from said location-sensitive data travel-related 
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6 information for the vehicle based on a location of the vehicle as reported by said 

7 geolocator, and 

8 means for delivering selected travel-related information to the vehicle for 

9 receipt by the mobile receiver. 

1 7. The system of claim 6 wherein said mobile transmitter and said mobile receiver 

2 are embodied in a cellular phone. 

l 8. The system of claim 6 wherein said mobile receiver is embodied in a pager. 

1 9. The system of claim 6 wherein said location-sensitive data includes travel time 

2 data for specific road segments. 

1 10. The system of claim 9 further including means for dynamically updating said 

2 location-sensitive data based on observed travel conditions. 


l 


11. The system of claim 10 wherein said means for dynamically updating includes 

2 means for updating said location-sensitive data using geolocation data from said 

3 geolocator. 

1 12. The system of claim 6 wherein said selection means selects a preferred route to 

2 a specified destination. 

1 13. The system of claim 12 wherein said selection means selects an estimated 

2 fastest route to said destination. 

1 14. The system of claim 6 wherein said selection means selects route guidance 

2 information. 

1 15. The system of claim 6 wherein said means for delivering includes means for 

2 notifying a user of the vehicle, on the basis of an estimated location of the vehicle relative 

3 to an anticipated route, before the vehicle passes a decision point at which the user must 

4 choose between two or more routes. 

1 16. A system for providing travel-related information to a user at a remote 

2 location, the system comprising 

3 means for accessing location-sensitive data, said location-sensitive data 
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4 including data obtained from passively geolocating and tracking one or more mobile 

5 transmitters, 

6 selection means for selecting travel-related information from said location- 

7 sensitive data based on one or more specified locations, and 

8 means for delivering selected travel-related information to the user. 


l 


l 


17. The system of claim 16 wherein said location-sensitive data includes travel 


2 time data. 


1 


18. The system of claim 16 further including means for dynamically updating said 

2 location-sensitive data based on observed travel conditions. 

1 19. The system of claim 18 wherein said means for dynamically updating includes 

2 means for updating said location-sensitive data using geolocation data obtained by 

3 passively geolocating mobile transmitters. 

1 20. The system of claim 16 wherein said selection means selects route guidance 

2 information. 

1 21. The system of claim 16 wherein said selection means selects a preferred route 

2 from a specified source to a specified destination. 


22. The system of claim 21 wherein said selection means selects an estimated 


2 fastest route from said source to said destination. 


23. The system of claim 21 wherein said location-sensitive data is updated 

2 dynamically based on observed travel conditions, and said system further comprises: 

3 means for storing a user profile, for a user, indicating a previously selected 

4 route from a source location to a destination location, and 

5 means for notifying the user if a newly selected route, from said source 

6 location to said destination location, differs from said previously selected route. 

1 24. The system of claim 21 further comprising means for computing an estimated 

2 arrival time of a vehicle at said destination. 

1 25. The system of claim 24 wherein said location-sensitive data is updated 
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2 dynamically based on observed travel conditions, and said system further comprises 

3 means for notifying a user at a remote location if said estimated arrival time differs from 

4 a previously estimated arrival time. 

1 26. The system of claim 17 further comprising means for computing an estimated 

2 departure time, from a specified source location, required to arrive at a specified 

3 destination location at a specified future time. 

1 27. The system of claim 26 further comprising means for notifying a user, at a 

2 remote location, when said departure time approaches. 

1 28. The system of claim 26 wherein said location-sensitive data is updated 

2 dynamically based on observed travel conditions, and said system further comprises 

3 means for notifying a user at a remote location if said estimated departure time differs 

4 from a previously estimated departure time. 

1 29. A method for generating map database information comprising the steps of 

2 accessing vehicle geolocation data obtained by passively geolocating at 

3 least one vehicle carrying a mobile transmitter, and 

4 processing said geolocation data by applying a prescribed algorithm: to 

5 select a tracking sequence representative of at least two reported positions of said vehicle; 

6 and to use said tracking sequence to estimate the location of at least one road segment to 

7 thereby generate the map database information. 

1 30. A method for generating map database information, comprising the steps of 

2 accessing vehicle geolocation data obtained by passively geolocating at 

3 least one vehicle carrying a mobile transmitter, and 

4 processing said geolocation data by applying a prescribed algorithm: to 

5 select a tracking sequence representative of at least two reported positions of a tracked 

6 vehicle; and to reconcile said tracking sequence against stored road location data in order 

7 to estimate a travel path of the tracked vehicle, along one or more road segments, 

8 corresponding to said tracking sequence, thereby generating the map database 

9 information. 
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1 31. The method of claim 30 wherein said vehicle geolocation data includes time 

2 stamps, and further comprising the step of computing an estimated vehicle travel time for 

3 at least one road segment along said travel path. 

1 32. The method of claim 31 further comprising the step of storing travel time data, 

2 for specific road segments, in a travel time database. 

1 33. A method for providing custom travel-related information to a vehicle carrying 

2 a mobile transmitter and a mobile receiver, the method comprising the steps of 

3 passively geolocating the mobile transmitter, 

4 accessing a database of location-sensitive data, 

5 selecting travel-related information from the database by applying a 

6 prescribed selection algorithm to produce the custom travel-related information based on 

7 at least one reported location of the vehicle, and 

8 delivering the custom travel-information to the mobile receiver; 

1 34. The method of claim 33 wherein said mobile transmitter and said mobile 

2 receiver are embodied in a cellular phone. 

l 35. The method of claim 33 wherein said mobile receiver is embodied in a pager. 

1 36. The method of claim 33 wherein said database of location-sensitive data 

2 includes travel time data for specific road segments. 

1 37. The method of claim 36 further including the step of dynamically updating 

2 said database of location-sensitive data based on observed travel conditions. 

1 38. The method of claim 37 wherein said step of dynamically updating includes 

2 the step of updating the location-sensitive data using geolocation data from said 

3 geolocator. 

1 39. The method of claim 33 wherein said selection algorithm selects a preferred 

2 route to a specified destination. 

1 40. The method of claim 39 wherein said selection algorithm selects an estimated 

2 fastest route to said destination. 
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41. The method of claim 33 wherein said selection algorithm selects route 


2 guidance information. 

1 42. The method of claim 33 further comprising the step of notifying the user of 

2 the vehicle, on the basis of an estimated location of the vehicle relative to an anticipated 

3 route, before the vehicle passes a decision point at which the user must choose between 

4 two or more routes. 

1 43. A method for providing travel-related information to a user at a remote 

2 location, comprising the steps of 

3 accessing a database of location-sensitive data, wherein said location- 

4 sensitive data includes data obtained from passively geolocating and tracking one or more 

5 mobile transmitters, 

6 selecting custom travel-related information from said database by applying 

7 a prescribed selection algorithm to produce the custom travel-related information based on 

8 at least one specified location, and 

9 delivering the selected travel-related information to the user. 

1 44. The method of claim 43 wherein said location-sensitive data includes travel 

2 time data. 

1 45. The method of claim 43 further including the step of dynamically updating 

2 said database of location-sensitive data based on observed travel conditions. 

1 46. The method of claim 45 wherein said step of dynamically updating includes 

2 the step of updating said location-sensitive data using geolocation data obtained by 

3 passively geolocating mobile transmitters. 

1 47. The method of claim 43 wherein said selection algorithm selects a preferred 

2 route from a specified source to a specified destination. 

1 48. The method of claim 47 wherein said selection algorithm selects an estimated 

2 fastest route from said source to said destination. 

1 49. The method of claim 43 wherein said selection algorithm selects route 

2 guidance information. 
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1 50. The method of claim 47 wherein said location-sensitive data is updated 

2 dynamically based on observed travel conditions, and said method further comprises the 

3 steps of 

4 storing a user profile, for the user, indicating a previously selected route 

5 from a source location to a destination location, and 

6 notifying the user if a newly selected route, from said source location to 

7 said destination location, differs from said previously selected route. 

1 51. The method of claim 47 wherein said selection algorithm computes an 

2 estimated arrival time of a vehicle at said destination. 

1 52. The method of claim 51 including the step of dynamically updating said 

2 location-sensitive data based on observed travel conditions, and further including the step 

3 of notifying the user if said estimated arrival time differs from a previously estimated 

4 arrival time. 

1 53. The method of claim 44 wherein said selection algorithm selects an estimated 

2 departure time, from a specified source location, required to arrive at a specified 

3 destination location at a specified future time. 

1 54. The method of claim 53 further comprising the step of notifying the user, at 

2 the remote location, when said departure time approaches. 

1 55. The method of claim 53 further including the step of dynamically updating 

2 said location-sensitive data based on observed travel conditions, and further including the 

3 step of notifying the user at the remote location if said estimated departure time differs 

4 from a previously estimated departure time. 
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